Johannes Berg wrote: > > Me neither, so I really need somebody to test this... I suspect there > will be problems when the device is set down because of rfkill, and then > we can no longer poll the rfkill hw state? But that might have been a > problem before too, since if my suspicion is right we could never do: > * hw rfkill > * set if down > * hw un-rfkill > * set if up > > and have it show the events to userspace as expected, or something... I'm trying to test, but I get an oops on boot. I'm still tracking it and I lose the reason off the top of the screen, but the trace is: queue_work + 0x1a schedule_work + 0x16 rfkill_resume_polling + 0x23 wiphy_rfkill_start_polling + 0x35 (Line 452 of net/wireless/core.c) b43_op_start + 0x172 (Line 4336 of drivers/net/wireless/b43/main.c) The offsets are appropriate for wireless-testing and x86_64. The line in b43_op_start is the one just before the mutex_unlock. Is it possible that we reached this point without hw->wiphy being set? Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
