fdo-mirrors/NetworkManager
1
0
Fork 0
mirror of https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git synced 2025-12-22 04:30:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
NetworkManager/src/nm-device-modem.c

507 lines
16 KiB
C
Raw Normal View History

modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
/* NetworkManager -- Network link manager
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
* Copyright (C) 2009 - 2011 Red Hat, Inc.
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
*/
#include <glib.h>
#include "nm-device-modem.h"
#include "nm-modem.h"
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
#include "nm-modem-cdma.h"
#include "nm-modem-gsm.h"
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
#include "nm-device-private.h"
#include "nm-properties-changed-signal.h"
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
#include "nm-rfkill.h"
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
#include "nm-marshal.h"
mobile-broadband: update logging
2010-04-07 11:08:43 -07:00
#include "nm-logging.h"
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
G_DEFINE_TYPE (NMDeviceModem, nm_device_modem, NM_TYPE_DEVICE)
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
#define NM_DEVICE_MODEM_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o), NM_TYPE_DEVICE_MODEM, NMDeviceModemPrivate))
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
#include "nm-device-modem-glue.h"
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
typedef struct {
NMModem *modem;
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
NMDeviceModemCapabilities caps;
NMDeviceModemCapabilities current_caps;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
} NMDeviceModemPrivate;
enum {
PROP_0,
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
PROP_MODEM,
PROP_CAPABILITIES,
PROP_CURRENT_CAPABILITIES,
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
};
enum {
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
PROPERTIES_CHANGED,
modem: fix WWAN hardware enable state tracking (rh #591622)
2010-05-24 17:07:46 -07:00
ENABLE_CHANGED,
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
LAST_SIGNAL
};
static guint signals[LAST_SIGNAL] = { 0 };
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
static void real_set_enabled (NMDevice *device, gboolean enabled);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
/*****************************************************************************/
static void
ppp_failed (NMModem *modem, NMDeviceStateReason reason, gpointer user_data)
{
NMDevice *device = NM_DEVICE (user_data);
core: kill nm_device_interface_get_state()
2011-11-17 22:50:36 -06:00
switch (nm_device_get_state (device)) {
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
case NM_DEVICE_STATE_PREPARE:
case NM_DEVICE_STATE_CONFIG:
case NM_DEVICE_STATE_NEED_AUTH:
nm_device_state_changed (device, NM_DEVICE_STATE_FAILED, reason);
break;
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
case NM_DEVICE_STATE_IP_CONFIG:
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
case NM_DEVICE_STATE_IP_CHECK:
case NM_DEVICE_STATE_SECONDARIES:
case NM_DEVICE_STATE_ACTIVATED:
mobile: ensure IPv4 timeout fails activation With the switch to IPv4 being allowed to fail by default we need to clean up this old code a bit. PPP failure during IP config should trigger a timeout, and the core code will handle whether to fail the device completely or not. But if we got a valid IPv4 config and PPP failed later, the device gets failed. Previously the device would just sit in IP_CONFIG state because now IPv4 defaults may-fail to TRUE, and when PPP failed the nm_device_ip_config_should_fail() check would obviously not pass.
2012-03-20 23:21:17 -05:00
if (nm_device_activate_ip4_state_in_conf (device))
nm_device_activate_schedule_ip4_config_timeout (device);
else {
core: allow selective failure of IP configuration (rh #567978) As long as at least one IP config method completes, and as long as methods that the user required to complete do complete, allow the connection to complete.
2010-05-03 01:19:54 -07:00
nm_device_state_changed (device,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE);
}
break;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
default:
break;
}
}
static void
modem_prepare_result (NMModem *modem,
gboolean success,
NMDeviceStateReason reason,
gpointer user_data)
{
NMDevice *device = NM_DEVICE (user_data);
NMDeviceState state;
core: kill nm_device_interface_get_state()
2011-11-17 22:50:36 -06:00
state = nm_device_get_state (device);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
g_return_if_fail (state == NM_DEVICE_STATE_PREPARE);
if (success)
nm_device_activate_schedule_stage2_device_config (device);
else
nm_device_state_changed (device, NM_DEVICE_STATE_FAILED, reason);
}
static void
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
modem_auth_requested (NMModem *modem, gpointer user_data)
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
{
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
nm_device_state_changed (NM_DEVICE (user_data),
NM_DEVICE_STATE_NEED_AUTH,
NM_DEVICE_STATE_REASON_NONE);
}
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
static void
modem_auth_result (NMModem *modem, GError *error, gpointer user_data)
{
NMDevice *device = NM_DEVICE (user_data);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
if (error) {
nm_device_state_changed (device,
NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_NO_SECRETS);
} else {
/* Otherwise, on success for modem secrets we need to schedule stage1 again */
g_return_if_fail (nm_device_get_state (device) == NM_DEVICE_STATE_NEED_AUTH);
nm_device_activate_schedule_stage1_device_prepare (device);
}
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
}
static void
modem_ip4_config_result (NMModem *self,
const char *iface,
NMIP4Config *config,
GError *error,
gpointer user_data)
{
NMDevice *device = NM_DEVICE (user_data);
core: decouple initial IP configuration states from device state Initial IP configuration can happen during ACTIVATED state if both v4 and v6 are enabled, but one takes longer than the other. Thus various checks throughout the code for IP_CONFIG were incorrect since they depended on IP configuration only happening during the IP_CONFIG state. Fix that by using a separate state for IP config and using that state for various checks instead of the overall device state.
2011-10-09 23:48:13 -05:00
g_return_if_fail (nm_device_activate_ip4_state_in_conf (device) == TRUE);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
if (error) {
mobile-broadband: update logging
2010-04-07 11:08:43 -07:00
nm_log_warn (LOGD_MB | LOGD_IP4, "retrieving IP4 configuration failed: (%d) %s",
error ? error->code : -1,
error && error->message ? error->message : "(unknown)");
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
nm_device_state_changed (device, NM_DEVICE_STATE_FAILED, NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE);
} else {
if (iface)
nm_device_set_ip_iface (device, iface);
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
nm_device_activate_schedule_ip4_config_result (device, config);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
}
}
static void
modem_enabled_cb (NMModem *modem, GParamSpec *pspec, gpointer user_data)
{
NMDeviceModem *self = NM_DEVICE_MODEM (user_data);
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (self);
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
real_set_enabled (NM_DEVICE (self), nm_modem_get_mm_enabled (priv->modem));
modem: fix WWAN hardware enable state tracking (rh #591622)
2010-05-24 17:07:46 -07:00
g_signal_emit (G_OBJECT (self), signals[ENABLE_CHANGED], 0);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
}
/*****************************************************************************/
NMModem *
nm_device_modem_get_modem (NMDeviceModem *self)
{
g_return_val_if_fail (self != NULL, NULL);
g_return_val_if_fail (NM_IS_DEVICE_MODEM (self), NULL);
return NM_DEVICE_MODEM_GET_PRIVATE (self)->modem;
}
/*****************************************************************************/
static void
device_state_changed (NMDevice *device,
NMDeviceState new_state,
NMDeviceState old_state,
NMDeviceStateReason reason,
gpointer user_data)
{
nm_modem_device_state_changed (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem,
new_state,
old_state,
reason);
}
static guint32
real_get_generic_capabilities (NMDevice *device)
{
return NM_DEVICE_CAP_NM_SUPPORTED;
}
static NMConnection *
real_get_best_auto_connection (NMDevice *device,
GSList *connections,
char **specific_object)
{
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (device);
return nm_modem_get_best_auto_connection (priv->modem, connections, specific_object);
}
static gboolean
real_check_connection_compatible (NMDevice *device,
NMConnection *connection,
GError **error)
{
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (device);
return nm_modem_check_connection_compatible (priv->modem, connection, error);
}
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
static gboolean
real_complete_connection (NMDevice *device,
NMConnection *connection,
const char *specific_object,
const GSList *existing_connections,
GError **error)
{
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (device);
return nm_modem_complete_connection (priv->modem, connection, existing_connections, error);
}
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
static gboolean
real_hw_is_up (NMDevice *device)
{
return nm_modem_hw_is_up (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem, device);
}
static gboolean
real_hw_bring_up (NMDevice *device, gboolean *no_firmware)
{
return nm_modem_hw_bring_up (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem, device, no_firmware);
}
static void
core: consolidate deactivation methods deactivate_quickly is misnamed these days; it was originally used for quickly tearing down a device for sleep and such. But these days it's used for the bulk of device deactivation. Only the wifi class used the actual deactivate method. So combine the two and make device implementations less complicated.
2011-02-24 11:27:42 -06:00
real_deactivate (NMDevice *device)
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
{
core: consolidate deactivation methods deactivate_quickly is misnamed these days; it was originally used for quickly tearing down a device for sleep and such. But these days it's used for the bulk of device deactivation. Only the wifi class used the actual deactivate method. So combine the two and make device implementations less complicated.
2011-02-24 11:27:42 -06:00
nm_modem_deactivate (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem, device);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
}
static NMActStageReturn
real_act_stage1_prepare (NMDevice *device, NMDeviceStateReason *reason)
{
NMActRequest *req;
req = nm_device_get_act_request (device);
g_assert (req);
return nm_modem_act_stage1_prepare (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem, req, reason);
}
static NMActStageReturn
real_act_stage2_config (NMDevice *device, NMDeviceStateReason *reason)
{
NMActRequest *req;
req = nm_device_get_act_request (device);
g_assert (req);
return nm_modem_act_stage2_config (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem, req, reason);
}
static NMActStageReturn
core: kill stage4 (IP Config Get) It was somewhat pointless since the IP config is always known when stage4 gets scheduled, so why not just pass the config to stage5 immediately? Also helps consolidate the v4/v6 failure handling logic and makes the operational flow clearer where both v4 and v6 are active and proceeding in parallel.
2011-10-09 22:50:04 -05:00
real_act_stage3_ip4_config_start (NMDevice *device,
NMIP4Config **out_config,
NMDeviceStateReason *reason)
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
{
return nm_modem_stage3_ip4_config_start (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem,
device,
NM_DEVICE_CLASS (nm_device_modem_parent_class),
reason);
}
core: treat missing IPv6 setting as AUTO Like IPv4, if the connection contains no IPv6 setting, perform IPv6 addressing. Since may-fail defaults to TRUE for IPv6, failure should have no consequence.
2012-03-16 09:43:16 -05:00
static NMActStageReturn
real_act_stage3_ip6_config_start (NMDevice *device,
NMIP6Config **out_config,
NMDeviceStateReason *reason)
{
return nm_modem_stage3_ip6_config_start (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem,
device,
NM_DEVICE_CLASS (nm_device_modem_parent_class),
reason);
}
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
/*****************************************************************************/
static gboolean
core: move nm_device_interface_get_enabled() to nm-device.c
2011-11-17 23:28:30 -06:00
real_get_enabled (NMDevice *device)
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
{
return nm_modem_get_mm_enabled (NM_DEVICE_MODEM_GET_PRIVATE (device)->modem);
}
static void
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
real_set_enabled (NMDevice *device, gboolean enabled)
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
{
NMDeviceModem *self = NM_DEVICE_MODEM (device);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (self);
NMDeviceState state;
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
if (priv->modem) {
nm_modem_set_mm_enabled (priv->modem, enabled);
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
if (enabled == FALSE) {
modem: ensure radio disable cleans up during activation too Instead of just when activated.
2012-06-04 18:43:18 -05:00
state = nm_device_get_state (device);
if (nm_device_is_activating (device) || state == NM_DEVICE_STATE_ACTIVATED) {
/* user-initiated action, hence DISCONNECTED not FAILED */
nm_device_state_changed (device,
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
NM_DEVICE_STATE_DISCONNECTED,
modem: ensure radio disable cleans up during activation too Instead of just when activated.
2012-06-04 18:43:18 -05:00
NM_DEVICE_STATE_REASON_USER_REQUESTED);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
}
}
}
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
}
/*****************************************************************************/
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
NMDevice *
nm_device_modem_new (NMModem *modem, const char *driver)
{
NMDeviceModemCapabilities caps = NM_DEVICE_MODEM_CAPABILITY_NONE;
const char *type_desc = NULL;
g_return_val_if_fail (modem != NULL, NULL);
g_return_val_if_fail (NM_IS_MODEM (modem), NULL);
g_return_val_if_fail (driver != NULL, NULL);
if (NM_IS_MODEM_CDMA (modem)) {
caps = NM_DEVICE_MODEM_CAPABILITY_CDMA_EVDO;
type_desc = "CDMA/EVDO";
} else if (NM_IS_MODEM_GSM (modem)) {
caps = NM_DEVICE_MODEM_CAPABILITY_GSM_UMTS;
type_desc = "GSM/UMTS";
} else {
nm_log_warn (LOGD_MB, "unhandled modem type %s", G_OBJECT_TYPE_NAME (modem));
return NULL;
}
return (NMDevice *) g_object_new (NM_TYPE_DEVICE_MODEM,
core: move NMDeviceInterface properties and methods to nm-device.c
2011-11-18 00:34:08 -06:00
NM_DEVICE_UDI, nm_modem_get_path (modem),
NM_DEVICE_IFACE, nm_modem_get_iface (modem),
NM_DEVICE_DRIVER, driver,
NM_DEVICE_TYPE_DESC, type_desc,
NM_DEVICE_DEVICE_TYPE, NM_DEVICE_TYPE_MODEM,
NM_DEVICE_RFKILL_TYPE, RFKILL_TYPE_WWAN,
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
NM_DEVICE_MODEM_MODEM, modem,
NM_DEVICE_MODEM_CAPABILITIES, caps,
NM_DEVICE_MODEM_CURRENT_CAPABILITIES, caps,
NULL);
}
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
static void
nm_device_modem_init (NMDeviceModem *self)
{
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
g_signal_connect (self, "state-changed", G_CALLBACK (device_state_changed), self);
}
static void
set_modem (NMDeviceModem *self, NMModem *modem)
{
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (self);
g_return_if_fail (modem != NULL);
priv->modem = g_object_ref (modem);
g_signal_connect (modem, NM_MODEM_PPP_FAILED, G_CALLBACK (ppp_failed), self);
g_signal_connect (modem, NM_MODEM_PREPARE_RESULT, G_CALLBACK (modem_prepare_result), self);
g_signal_connect (modem, NM_MODEM_IP4_CONFIG_RESULT, G_CALLBACK (modem_ip4_config_result), self);
core: simplify secrets handling during activation Instead of a bizare mechanism of signals back to the manager object that used to be required because of the user/system settings split, let each place that needs secrets request those secrets itself. This flattens the secrets request process a ton and the code flow significantly. Previously the get secrets flow was something like this: nm_act_request_get_secrets () nm_secrets_provider_interface_get_secrets () emits manager-get-secrets signal provider_get_secerts () system_get_secrets () system_get_secrets_idle_cb () nm_sysconfig_connection_get_secrets () system_get_secrets_reply_cb () nm_secrets_provider_interface_get_secrets_result () signal failure or success now instead we do something like this: nm_agent_manager_get_secrets () nm_agent_manager_get_secrets () request_start_secrets () nm_sysconfig_connection_get_secrets () return failure or success to callback
2010-12-13 13:11:51 -06:00
g_signal_connect (modem, NM_MODEM_AUTH_REQUESTED, G_CALLBACK (modem_auth_requested), self);
g_signal_connect (modem, NM_MODEM_AUTH_RESULT, G_CALLBACK (modem_auth_result), self);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
g_signal_connect (modem, "notify::" NM_MODEM_ENABLED, G_CALLBACK (modem_enabled_cb), self);
}
static void
set_property (GObject *object, guint prop_id,
const GValue *value, GParamSpec *pspec)
{
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (object);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
switch (prop_id) {
case PROP_MODEM:
/* construct-only */
set_modem (NM_DEVICE_MODEM (object), g_value_get_object (value));
break;
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
case PROP_CAPABILITIES:
priv->caps = g_value_get_uint (value);
break;
case PROP_CURRENT_CAPABILITIES:
priv->current_caps = g_value_get_uint (value);
break;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
}
static void
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
get_property (GObject *object, guint prop_id,
GValue *value, GParamSpec *pspec)
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
{
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (object);
switch (prop_id) {
case PROP_MODEM:
g_value_set_object (value, priv->modem);
break;
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
case PROP_CAPABILITIES:
g_value_set_uint (value, priv->caps);
break;
case PROP_CURRENT_CAPABILITIES:
g_value_set_uint (value, priv->current_caps);
break;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
}
}
static void
finalize (GObject *object)
{
NMDeviceModemPrivate *priv = NM_DEVICE_MODEM_GET_PRIVATE (object);
g_object_unref (priv->modem);
priv->modem = NULL;
G_OBJECT_CLASS (nm_device_modem_parent_class)->finalize (object);
}
static void
nm_device_modem_class_init (NMDeviceModemClass *mclass)
{
GObjectClass *object_class = G_OBJECT_CLASS (mclass);
NMDeviceClass *device_class = NM_DEVICE_CLASS (mclass);
g_type_class_add_private (object_class, sizeof (NMDeviceModemPrivate));
/* Virtual methods */
object_class->finalize = finalize;
object_class->get_property = get_property;
object_class->set_property = set_property;
device_class->get_generic_capabilities = real_get_generic_capabilities;
device_class->get_best_auto_connection = real_get_best_auto_connection;
device_class->check_connection_compatible = real_check_connection_compatible;
core: add AddAndActivate D-Bus method Given connection details, complete the connection as well as possible using the given specific object and device, add it to system settings, and activate it all in one method.
2011-01-10 23:39:12 -06:00
device_class->complete_connection = real_complete_connection;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
device_class->hw_is_up = real_hw_is_up;
device_class->hw_bring_up = real_hw_bring_up;
core: consolidate deactivation methods deactivate_quickly is misnamed these days; it was originally used for quickly tearing down a device for sleep and such. But these days it's used for the bulk of device deactivation. Only the wifi class used the actual deactivate method. So combine the two and make device implementations less complicated.
2011-02-24 11:27:42 -06:00
device_class->deactivate = real_deactivate;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
device_class->act_stage1_prepare = real_act_stage1_prepare;
device_class->act_stage2_config = real_act_stage2_config;
device_class->act_stage3_ip4_config_start = real_act_stage3_ip4_config_start;
core: treat missing IPv6 setting as AUTO Like IPv4, if the connection contains no IPv6 setting, perform IPv6 addressing. Since may-fail defaults to TRUE for IPv6, failure should have no consequence.
2012-03-16 09:43:16 -05:00
device_class->act_stage3_ip6_config_start = real_act_stage3_ip6_config_start;
core: move nm_device_interface_get_enabled() to nm-device.c
2011-11-17 23:28:30 -06:00
device_class->get_enabled = real_get_enabled;
core: move nm_device_interface_set_enabled() to nm-device.c
2011-11-17 23:38:08 -06:00
device_class->set_enabled = real_set_enabled;
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
/* Properties */
g_object_class_install_property
(object_class, PROP_MODEM,
g_param_spec_object (NM_DEVICE_MODEM_MODEM,
"Modem",
"Modem",
NM_TYPE_MODEM,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY | NM_PROPERTY_PARAM_NO_EXPORT));
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
g_object_class_install_property (object_class, PROP_CAPABILITIES,
g_param_spec_uint (NM_DEVICE_MODEM_CAPABILITIES,
"Modem Capabilities",
"Modem Capabilities",
0, G_MAXUINT32, NM_DEVICE_MODEM_CAPABILITY_NONE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY));
g_object_class_install_property (object_class, PROP_CURRENT_CAPABILITIES,
g_param_spec_uint (NM_DEVICE_MODEM_CURRENT_CAPABILITIES,
"Current modem Capabilities",
"Current modem Capabilities",
0, G_MAXUINT32, NM_DEVICE_MODEM_CAPABILITY_NONE,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT_ONLY));
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
/* Signals */
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
signals[PROPERTIES_CHANGED] =
nm_properties_changed_signal_new (object_class,
G_STRUCT_OFFSET (NMDeviceModemClass, properties_changed));
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
modem: fix WWAN hardware enable state tracking (rh #591622)
2010-05-24 17:07:46 -07:00
signals[ENABLE_CHANGED] =
g_signal_new (NM_DEVICE_MODEM_ENABLE_CHANGED,
G_OBJECT_CLASS_TYPE (object_class),
G_SIGNAL_RUN_FIRST,
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
0, NULL, NULL,
modem: fix WWAN hardware enable state tracking (rh #591622)
2010-05-24 17:07:46 -07:00
g_cclosure_marshal_VOID__VOID,
G_TYPE_NONE, 0);
modem: consolidate common modem code into NMDeviceModem
2010-03-25 13:15:03 -07:00
dbus_g_object_type_install_info (G_TYPE_FROM_CLASS (mclass),
core: consolidate mobile broadband device types These days more and more devices are showing up that support a number of different access technology families in the same hardware, like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM), Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra 320U (GSM and LTE), etc. The previous scheme of having device classes based on access technology family simply cannot handle this hardware and attempting to add LTE to both the CDMA and GSM device classes would result in a bunch of code duplication that we don't want. There's a better way... Instead, combine both CDMA and GSM device classes into a generic "Modem" device class that provides capabilities indicating what access technology families a modem supports, and what families it supports immediately without a firmware reload. (Gobi devices for example require a firmware reload before they can switch between GSM and CDMA). This provides the necessary flexibility to the client and allows us to keep the API stable when the same consolidation change is made in ModemManager. The current code doesn't yet allow multi-mode operation internally, but the API is now what we want it to be and won't need to be changed.
2011-02-25 10:16:17 -06:00
&dbus_glib_nm_device_modem_object_info);
modem: fix modem type checking for various operations After the DUN branch merge (I think?) a number of NM_IS_MODEM calls were left around which now always return FALSE since NMDeviceCdma and NMDeviceGsm aren't subclasses of NMModem anymore. But we still need generic "is this a modem subclass" checks in a few places, so add a modem base class that both the GSM and CDMA device classes inherit from and use that. Plus, we want to consolidate a ton of the common code in nm-device-gsm.c and nm-device-cdma.c into the base class in the future anyway.
2010-03-25 12:18:26 -07:00
}
Reference in a new issue Copy permalink