Re: driver callback naming

2009-08-30 Thread Denis Kenzior
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

Re: driver callback naming

2009-08-30 Thread Andres Salomon
On Sun, 30 Aug 2009 13:45:45 -0500 Denis Kenzior denk...@gmail.com wrote: Hi Andres, static struct ofono_modem_driver g1_driver = { .name = HTC G1, .probe = g1_probe, .enable = g1_enable, .disable = g1_disable, .remove = g1_remove,

Re: driver callback naming

2009-08-30 Thread Aki Niemi
2009/8/30 Denis Kenzior denk...@gmail.com: 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. For airplane mode, you want to turn off the radios. I'm

Re: driver callback naming

2009-08-30 Thread Denis Kenzior
Hi Andres, 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

Re: driver callback naming

2009-08-30 Thread Denis Kenzior
Hi Aki, 2009/8/30 Denis Kenzior denk...@gmail.com: 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. For airplane mode, you want to turn off