On Saturday 11 October 2008, Dave wrote: > Andrey Borzenkov wrote: > > On resume card state is likely lost so we have to reload firmware > > again. > > > > Signed-off-by: Andrey Borzenkov <arvidjaar@xxxxxxx> > > > > --- > > > > This is non-functional without second patch. Currently you simply > > have no way to load request firmware from user space in ->resume. > > Does it work when you compile the firmware into the kernel image > with CONFIG_FIRMWARE_KERNEL, CONFIG_EXTRA_FIRMWARE and > CONFIG_EXTRA_FIRMWARE_DIR? > I assume yes - but the resulting binary cannot be redistributed, so it of little help; it means, orinoco driver in distributions still won't work out of the box. [From another mail] > Spectrum_cs has had firmware download for a while. It achieves the firmware > reload on resume by doing schedule_work(&priv->reset_work). > > Would the same work for orinoco_cs? You (currently) have no way to synchronize reset_work with unfreezing other tasks. It may work most of the time but it may as well fail every now and then. Also spectrum_cs is obviously broken - it claims hardware and interface are available *before* they are actiually available. This again is hard to debug race condition. It is planned to add pre-freeze notifiers; in this case we could use them to load firmware before suspend. But right now I do not see how this situation is different from compiling firmware in module except that it is more clean from legal point of view. Personally I prefer to use it right now (ideally in 2.6.28; do not know who decides) and return to it later when we have better interfaces. > > + int err = 0; > > The explicit initialisation is unneccesary. OK it is leftover; I tried first to load firmware before hermes_init; it worked for STR and failed for STD. I'll remove it; thank you.
Attachment:
signature.asc
Description: This is a digitally signed message part.
