orinoco_cs, timeouts retrieving firmware during suspend/resume

[Dave Kilroy]

On Thu, Dec 9, 2010 at 2:58 AM, Giacomo Comes <comes at naic.edu> wrote:
> On Wed, Dec 08, 2010 at 07:24:47PM +0000, Dave Kilroy wrote:
>> On Mon, Dec 6, 2010 at 9:25 PM, Giacomo Comes <comes at naic.edu> wrote:
>> > On Mon, Dec 06, 2010 at 06:43:04PM +0000, Dave Kilroy wrote:
>> >> > The only issue still not fixed is the suspend/resume timeout.
>> >> > Can you help also with that?
>> >>
>> >> Absolutely. With the latest patches, please just do a suspend resume,
>> >> and post the dmesg output. Also let me know what the value of
>> >> CONFIG_HERMES_CACHE_FW_ON_INIT is.
>> >
>> > CONFIG_HERMES_CACHE_FW_ON_INIT=y
>> >
>> > Attached is the outpur of dmesg after suspend/resume
>> >
>> > As you can see, the driver is unable to load the firmware,
>> > therefore WPA is not available after resume:
>>
>> I've had a look at the log. Things aren't working as I'd expect.
>> orinoco_init is being called on resume, which I don't think used to
>> happen. That is what is causing the request for firmware, and the
>> delay on resume.
>>
>> Instead I only expected orinoco_up to get called. I'll dig around to
>> see whether that's a change in the kernel. It might be distro specific
>> though. Do you know if suse works differently on suspend/resume? i.e
>> explicitly 'modprobe -r'ing drivers
>>
>> Dave.
>
> After more investigation, I have found that
> suspend/resume works if I suspend the system from the console
> with the command s2disk even if the orinoco module is loaded.
>
> When I suspend the system from the desktop calling pm-hibernate
> then there is the delay. Remember, the delay happens on suspend
> AND on resume.
> pm-hibernate will run a set of scripts in /usr/lib/pm-utils/sleep.d
> One of these scripts (45pcmcia) executes:
> "/sbin/pccardctl eject" on suspend and
> "/sbin/pccardctl insert" on resume.
>
> If I disable this script, then suspend/resume works properly.
>
> I wonder if there are other pcmcia wireles cards that suffer
> the same problem?
>
> What is, in your opinion, the proper way to proceed?
> To change something in the orinoco driver? Modify pm-utils?
> Something else?

cc'ing linux-pcmcia in case someone there has a recommendation. Quick
problem summary: delay during suspend and resume caused by pm scripts
detaching and reattaching cards - this is causing the driver to
attempt to retrieve firmware (which is timing out).

The question is whether a driver can rely on a call to
request_firmware during it's _init/_probe call. Clearly it works on
startup.

I think the most flexible solution would be to move all the firmware
loading for orinoco out of _init and into _up (which I believe is the
general recommendation for wireless). Some of the preliminary work to
do this has been done (pushing reading of card settings into a helper
function).

A particular problem for orinoco is that without attempting to load
firmware, you don't know the driver capabilities. Therefore we can't
register with cfg80211 with the drivers actual capabilities.

Another way to go is to ensure we can still make request-firmware
calls when the pm scripts are run. I'm sure there's a conflicting
requirement somewhere that prevents this though...

Finally, orinoco could call request_firmware_nowait instead. That will
eliminate the delays on suspend and resume, but you will generally
lose WPA capability across a suspend.


Regards,

Dave