brian.xu wrote:
>
>
> Garrett D'Amore ???:
>
>> Disclaimer: I wrote Tadpole's closed-source PRISM wireless LAN driver
>> (PRISM 2.5 miniPCI only). I was looking at pcwl to see what it would
>> take to migrate some of our drivers and tools to the new Solaris
>> wificonfig framework.
>>
>>
> The new pcwl driver(not posted on opensolaris) supports PRISM 2.5
> miniPCI.
> One thing strange to me is I don't know how the driver of Tadpole deal
> with the RF switch(a button on the front panel).
On our SPARC platforms, it is dealt with entirely in hardware and low
level platform firmware. Most miniPCI adapters have a special pin on
them that can be tied to an RF button, and they usually do something
sensible with it. So with miniPCI it is *almost* automatic. The
problem is that on x86 hardware there is often ACPI getting in the way.
Does the new code properly ensure that overlapping accesses to buffer
paths 0 and 1 are not used on miniPCI hardware? There is a known errata
in miniPCI where overlapping accesses to channels 0 and 1 can cause a
hardware hang. The only software workaround is to guarantee a minimum
delay between accesses to paths, or restrict accesses to only a single
path. (I chose the latter approach.)
What about firmware updates? There are problems with PRISM devices that
are fixed with firmware updates, and some newer PRISM devices (PRISM 3)
_require_ a RAM firmware upload, because they lack sufficient flash
memory to hold the run-time firmware image ("secondary firmware" in
Intersil parlance) on device.
I would like to get a copy of the code if possible. I may be able to
review it for known problems and send any appropriate fixes.
That begs another question, which is how do I participate more fully in
this community? It is likely going forward that I will have code
enhancements that comes from my not-insignificant experience working on
kernel support for Solaris with WIFI and other laptop-oriented devices,
and that I'd like to be able to contribute these enhancements or fixes
back to the community.
As another example, I recently updated the Atheros HAL on NetBSD, and
would like to do so on Solaris as well -- including a HAL for SPARC
systems! There are ABI changes (minor), and I'm sure I could make those
changes and test them myself, but I have no idea what the process is to
submit such changes back to the community.
I have a freeware driver for certain ethernet chips (quite common in
Cardbus controllers, btw) that I've been trying to get integrated into
Solaris for _years_ now, and it still seems to be languishing. So
clearly I need more advice about how to share back with OpenSolaris.
(FWIW, I am a former Sun employee myself, and I've worked with PSARC,
etc. in the past. So I know how to do it the old way -- which if you
weren't a Sun employee was impossible. But I don't know the "new"
OpenSolaris way. :-)
>
>> I noticed that in pcwl, there is a delay() call done in pcwl_getset
>> (for the site survey scan), which is called from ioctl. As this
>> ioctl is a STREAMs routine, it poor form (and actually unsafe!) to
>> block/delay. Unless Solaris 10 has done something to change the
>> semantics for STREAMs that I'm unaware of.
>>
>>
>>
> correct.
> ioctl in the driver will held the rwlock of gld, then if the thread of
> ioctl is interrupted by rx routine, and the rx routine calls gld_recv,
> deadlock may happen.
Right. Thou shalt not block/sleep in STREAMs routines (including all
GLD entry points) other than open and close. (Sleep in DDI
attach/detach is OK, of course.)
This isn't the only driver that makes this mistake, and it will rarely
cause a problem, but it should be fixed.
>
>> What needs to happen is this call has to unfortunately be split up
>> and handled asynchronously. Its a royal pain in the neck, but that
>> is the only safe way to do this.
>>
>>
>>
> I think I don't catch up with your meaning. '/split up and handled
> asynchronously/' means what?
The handling gets split up along these lines:
ioctl starts long running command on hardware, and arranges timeout.
returns _without_ sending any message back upstream.
timeout wakes up, finishes processing, and qreply()'s with M_IOCACK or
whatever.
This is more complicated for drivers that use perimeters. But gld
doesn't fall into that category. But you still have to ensure that
close() doesn't close the stream while the ioctl is still outstanding,
to avoid having an unreferenced queue used in the timeout.
Unfortunately, GLD has no protection for this, so you really should wrap
gld_close with your own routine.
Normally even this isn't a problem, since generally ioctl in userland
blocks, so you don't see close() with an outstanding ioctl. But I think
it could happen in the event that the process is killed.
Because of all of these complications, I found it much easier in my code
to split the scanning logic into two ioctls. The first ioctl asked the
hardware to initiate a scan. The 2nd ioctl reads the results.
>
>> Btw, I just "joined" this community, and I hope to be able to
>> participate more going forward, including more involvement from my
>> employer (formerly Tadpole, now a division of General Dynamics.)
>>
>>
>>
> welcome to the community.
Thanks. See my question above regarding contribution of code, etc.
-- Garrett
>
>>
>> This message posted from opensolaris.org
>> _______________________________________________
>> laptop-discuss mailing list
>> laptop-discuss at opensolaris.org
>>
>>
--
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134 Fax: 951 325-2191
