Re. all this talk about drivers left and right - using iPhone, N95 or <insert device>'s driver. These are all binary drivers. What would be useful for a Linux/ARM driver would be source code for the abovementioned drivers, as at least that could in principle be used to deduce enough of the workings of the chipset to write a proper Linux driver.

However, with binary drivers you would have to reverse engineer from the binary code, which is simply utter pain for the code of almost any modern CPU. (I mean, it can be done, but there's so many more fun things to do in life..)

The other way of using a binary driver would be to use a "wrapper", but to do that you need a well-defined ABI that you _know_ the driver is using. It's been done before, e.g. with the 'ndiswrapper' project for x86 Linux. It's a wrapper which can load Windows wireless network drivers written for the Windows 'NDIS' ABI. It works very well, however it's a project that's taken _years_ to get to today's very stable level, and it's for a driver ABI that is not only well-defined, Windows drivers are also rigidly tested for compliance. Also note that the NDIS specification is much easier to wrap than many other driver specs, because it defines a lot of operating _calls_ that the drivers must use instead of accessing data etc. directly. This makes it much easier to write a wrapper - you just write your version of the functions that the driver needs to call.

There's a reason there are not that many binary driver wrappers out there.. it _sounds_ like the easy way, but every other solution is almost always less work.