>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.
>
>
understood.
>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.)
>
>
>
I have not noticed it yet.I did not suffer with hardware hang due to the
errata.
Just as the pcwl driver, channel 0 and 1 is separately used as cmd and
data path.
>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.
>
>
>
that driver doesn't support firmware update.
>I would like to get a copy of the code if possible.
>
surely. I will post it on opensolaris soon.
> I may be able to
>review it for known problems and send any appropriate fixes.
>
>
thanks.
>
>
> 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.)
>
>
Yes.
>This isn't the only driver that makes this mistake, and it will rarely
>cause a problem, but it should be fixed.
>
>
>
I develop&debug realtek wifi driver recently and encounter such a deadlock.
since 'scan' is not invoked frequently, I use a spin wait--drv_usecwait().
>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.
>
>
>
wificonfig split the scan logic into two ioctls as you said. so the driver
can also fulfil it.
Thanks,
Brian
