bluetooth tests don't rfkill unblock before running.

While it may not be a blocker, shouldn't this also be escalated if it
does affect BT after suspend?

If my BT is not blocked before suspend, I suspend the machine, resume
the machine and discover that BT is now blocked (soft or hard) that
should be a bug because the system didn't return to the previous working
state.

--
Jeff Lane - Hardware Certification Engineer and Test Tools Developer
Ubuntu Ham: W4KDH
Freenode IRC: bladernr or bladernr_
gpg: 1024D/3A14B2DD 8C88 B076 0DD7 B404 1417 C466 4ABD 3635 3A14 B2DD

Yes, I'll try and make a point of raising bugs if I see it again

Thinking about this a bit, it might be good to handle this as a warning in some way. We don't want these issues to slide under our radar, but at the same time it's not productive to have to rerun Bluetooth tests because of this. The tests should spit out 'BT is soft blocked, unblocking for test purposes' and then run the actual test. At this point the question is whether to fail or pass the test. Failing it makes the problem of it being blocked more noticable, but clogs up the results. I'll have to make a call on that. Potentially the test can also point out hard block, but that cannot be removed prior to the test, so it will fail anyway.