libQMI - developed and extended….

[Dan Williams]

On Mon, 2011-10-24 at 18:07 +0200, Markus Gothe wrote:
> 24 okt 2011 kl. 16:35 skrev Dan Williams <dcbw at redhat.com>:
> 
> > On Sun, 2011-10-23 at 16:50 +0200, Markus Gothe wrote:
> >> Last night I sat up hacking at the GobiDrivers and figured out a way to speedup the probing of modems (and some other tweaks)... By whitelisting the EPs for the specific VID (& PID)... Pretty much inspired by the option and sierra-net drivers. Now from taking a very long time on probing non-Gobi-modems it's is blazing fast. ;-) Apparently I applied the endian-fixes correctly, but one thing bothers me... the MEID. What is it and how is it represented. I know it is like 14 bytes. (Fixing that to be endian-wise will make me go crazy on bit-operations ;-) )...
> > 
> > It's the Mobile Equipment Identifier, which is the CDMA equivalent of
> > the IMEI that GSM/UMTS/LTE use.  All devices that support CDMA/EVDO will
> > have an MEID.
> 
> This explains things well I'll make a function for arbitrary length (read: slow) byteswapping...
> > 
> > But good work on making that part faster, the code there does a lot of
> > stuff it doesn't really need to do...
> > 
> > In the end though, a lot of the device detection code in there is
> > completely bogus.  What the process *should* be is to grab the port's
> > kernel driver name via udev, and if the device is driven by qcserial or
> > qcnet (when that ever gets merged), then handle it.  The code does a lot
> > of sysfs parkour that could be completely eliminated by just talking to
> > udev instead.
> 
> Will udev is nice it doesnt fit into the embedded industry where the memory footprint is thight. I suggest keeping the old way and implement udev and use an #ifdef to define which method to use.

Heh.  Even embedded devices use udev these days; I've seen udev on
consumer WiFi routers (ie, D-Link, others) with small amounts of flash
and RAM.  It's in phones too (anything from Palm I think).  I don't
believe it's a significant blocker.  We might be able to make udev
optional, but I'm unless it's really easy to do so, I'm not sure it's
worth the additional code.

> The option driver works instead of Gobiserial hanging the kernel.

Yeah, but the qcserial driver is the correct way to talk to the serial
ports on Gobi devices.  I wouldn't even bother with the upstream
Qualcomm GobiSerial driver, since that was cleaned up *extensively* a
few years ago to be submitted to the kernel.

> > 
> >> Elly, I see in the Chroniuom src that you've replaced the khtread with a workqueue. What's the reason for this and not using a tasklet?
> > 
> > That I'm not 100% sure about.
> 
> All I know is that the kthread polling is dead slow on embedded systems: Think 200MHz RISC CPU. Maybe I will have to do some inline asm... However the issues we experienced with unloading the driver was fixed by my optimization.

I don't like to use kthreads if I can help it, largely because a whole
thread usually isn't required for this sort of thing.

Dan