Re: [PATCH] Provide refrigerator support for irda

[Pavel Machek <pavel@suse.cz>]

Hi!

> > > Admittedly I didn't care about swsusp so far. Given the big fat warning on 
> > > top of Documentation/swsusp.txt I would not even try and i personally 
> > > don't see what I would miss without swsusp.
> > 
> > That's okay... Just support your DMA-ing devices are supported.
> 
> No matter whether it would be ISA-DMA or PCI busmastering I guess?

Any DMA is a problem.

> Not sure whether we can claim most irda drivers ready for swsusp then.
> vlsi_ir should be fine and for irda-usb I assume it would be up to the
> hcd - but don't know about the others...

Well, at least SIR should work as it works over normal serial, IIRC.

> > If it is possible to sleep at place "a", and no locks needed for
> > suspend are held at "a", inserting 
> > 
> > 	if (current->flags & PF_FREEZE)
> > 		refrigerator(PF_IOTHREAD);
> > 
> > is the right thing to do.
> 
> Ok, so the proposed patch is doing the right thing and should be applied.
> 
> Pavel, two more questions:
> 
> * For a kernel compiled with CONFIG_SWSUSP=n, may I assume PF_FREEZE would 
>   never be set or at least refrigerator would be noop?

PF_FREEZE is 0 so if() never succeeds.

> * Isn't there a race on SMP (and probably UP with CONFIG_PREEMPT) when 
>   PF_FREEZE gets modified by another cpu right after the test?

Only task itself ever clears its PF_FREEZE. That means there should be
no problem.
									Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]