Hi Andres,

> static struct ofono_modem_driver g1_driver = {
>         .name = "HTC G1",
>         .probe = g1_probe,
>         .enable = g1_enable,
>         .disable = g1_disable,
>         .remove = g1_remove,
>         .populate = g1_populate,
> };
>

So the current intention:
.probe - Detect whether device is really supported by the plugin, initialize 
any data structures specific to the device
.remove - Destroy data structures
.enable - Perform power up
.disable - Perform power down
.populate - Populate the atoms supported by this device (e.g. netreg, 
voicecall, etc)  This is called by the core after every power cycle, when the 
device is brought up.

>
> Of course, I'm also wondering why there needs to be two separate layers
> of calls in the first place.  Why not have drivers register everything
> from within probe, call ofono_set_powered(modem, TRUE) once the device
> is ready, and be done with it?

The reason for this is e.g. airplane mode, where you physically want to turn 
off the device.  Another case is for battery / power reasons, e.g. a netbook 
with a USB modem that is not being used.

> The only reason why this doesn't blow up in the generic_at plugin is
> because the driver_data is leaked.  If one were to free it from
> generic_at_exit in the wrong place (since it's allocated from
> generic_at_init, it would make sense to free it in generic_at_exit),
> one would see the same SEGV/SIGBUS/SIGILL errors upon ctrl-c.

So the leak has now been fixed.

I think you're being unnecessarily harsh here.  To be fair, the generic_at 
driver does something like this at init:

create generic_data
create modem
set modem data
register modem

If you were to reverse the steps, e.g.:
remove_modem
destroy generic_data

everything would work just fine.

Regards,
-Denis