On Tue, Aug 11, 2009 at 11:08:33AM -0700, reinette chatre wrote: > Hi Stanislaw, > > Thank you for your patience ... Hello, I understand your concerns, patch is not so straightforward and hard to understand, if you don't have system where you can reproduce. > On Tue, 2009-08-11 at 07:09 -0700, Stanislaw Gruszka wrote: > > On Mon, Aug 10, 2009 at 09:44:52AM -0700, reinette chatre wrote: > > > Yes. I assume that what happens here is that rfkill notifies user that > > > state changes to RFKILL_STATE_UNBLOCKED. In your new patch the driver > > > will now clear STATUS_RF_KILL_SW, with STATUS_RF_KILL_HW still being > > > set. So, in this run, after iwl_rfkill_soft_rf_kill is called there will > > > be a state mismatch with rfkill thinking the system is unblocked while > > > the driver has it as hard blocked. This is not right. > > > > In such case we return -EBUSY from iwl_rfkill_soft_rf_kill() - rfkill > > state not change. > > oh - right - sorry > > > I made a comment it will be HARD_BLOCKED, this > > is not true anymore, it can be also in state SOFT_BLOCKED . > > How so? Isn't the idea behind toggle_radio that the SOFT_BLOCKED state > changes? In this case when we get a new state of UNBLOCKED then I do not > understand how SOFT_BLOCKED can be true also. Hugh, right I was completely wrong here. > > However > > comment was true with previous version of the patch for 2.6.29, where > > there was no HARD -> SOFT downgrade and that part was called only when > > rfkill state was HARD_BLOCKED. > > > > > Can this be fixed by adding a iwl_rfkill_set_hw_state in this run? > > > > We can not call iwl_rfkill_set_hw_state in iwl_rfkill_soft_rt_kill > > as rfkill->muttex is taken. We eventually can force state in the same ugly > > way as is done for case RFKILL_STATE_SOFT_BLOCKED and I think, this is good > > idea :) , below not tested delta patch: > > > > This just seems to mess with the rfkill internals even more. Can this > not be avoided? Other solution eventually would be ignore rfkill core request to SW disable radio when we have already STATUS_RF_KILL_HW=1, but I think it is very bad idea and probably broke thinks. We currently call rfkill_force_state() which is changing internal state of rfkill core, however it is done through defined api. Uh, patch is not ideal, but I do not have anything better. > > > >From what I can tell this patch introduced a disagreement of rfkill > > > state between driver and rfkill system. > > > > In driver we have no states, but separate bits for each killswitch. Situation > > gets better after rfkill rewrite where also rfkill core become to have separate > > bits, but with 2.6.30 we have no such luck. > > > > Currently we have "states" like below: > > > > STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_HARD_BLOCKED > > STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED > > STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_HARD_BLOCKED > > STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_UNBLOCKED > > > > Patch is intended to work like that: > > > > STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED > > STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=1 <-> RFKILL_STATUS_SOFT_BLOCKED > > STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_HARD_BLOCKED > > STATUS_RF_KILL_HW=0 STATUS_RF_KILL_SW=0 <-> RFKILL_STATUS_UNBLOCKED > > I can see that this is what the last hunk of the patch accomplishes - > but I do not see why it is needed. > > > > > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > > > > driver HW on > > > > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED > > > > rfkill SW on ( -> rfkill_epo() -> rfkill_toggle_radio() with force = 1) > > > > STATUS_RF_KILL_HW=1, STATUS_RF_KILL_SW=1, RFKILL_STATE_HARD_BLOCKED > > > > rfkill SW off (HARD_BLOCKED not clearing STATUS_RF_KILL_SW) > > > > STATUS_RF_KILL_HW=1, STATUS_RF_KILL_SW=1, RFKILL_STATE_HARD_BLOCKED > > > > driver HW off (called from iwl_bg_rf_kill()) > > > > STATUS_RF_KILL_HW=0, STATUS_RF_KILL_SW=1, RFKILL_STATE_SOFT_BLOCKED > > > > rfkill core no longer wants to turn radio on > > >From what I understand what you are describing above should be addressed > by this hunk of your patch: > > case RFKILL_STATE_UNBLOCKED: > if (iwl_is_rfkill_hw(priv)) { > err = -EBUSY; > - goto out_unlock; > + /* pass error to rfkill core to make it state HARD > + * BLOCKED and disable software kill switch */ > } > > This should make these new transitions possible: > > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > driver HW on > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED > rfkill SW on ( -> rfkill_epo() -> rfkill_toggle_radio() with force = 1) > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_HARD_BLOCKED > rfkill SW off > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED No, rfkill core will not call ->toggle_radio() STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_HARD_BLOCKED > driver HW off (called from iwl_bg_rf_kill()) > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED Would be: STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 1, RFKILL_STATE_UNBLOCKED Not work without the patch, with patch it works like that: STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED driver HW on STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED rfkill SW on rfkill call -> rfkill_epo() -> rfkill_toggle_radio(RFKILL_STATE_SOFT_BLOCKED) with force = 1 . Due to changes in iwl_rfkill_soft_rf_kill() we move state to RFKILL_STATE_SOFT_BLOCKED, so: STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED rfkill SW off rfkill core call ->toggle_radio(RFKILL_STATE_UNBLOCKED) iwl_is_rfkill_hw(priv) is true but we disable STATUS_RF_KILL_SW anyway and return -EBUSY to not change rfkill core state, so: STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_SOFT_BLOCKED driver HW off STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > Looking further I tried to see how other combinations would be treated. Here is how I see the potential scenarios: > > Case1 (considered above): > driver HW on -> rfkill SW on -> rfkill SW off -> driver HW off > Case2: > driver HW on -> rfkill SW on -> driver HW off -> rfkill SW off > Case3: > rfkill SW on -> driver HW on -> rfkill SW off -> driver HW off > Case4: > rfkill SW on -> driver HW on -> driver HW off -> rfkill SW off > > Looking at the rest of the cases I do not see the problem addressed by the other hunks. > > I see: > > Case 2: > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > driver HW on > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED > rfkill SW on > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_HARD_BLOCKED > driver HW off > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED > rfkill SW off > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED Yes, works without the patch. > Case3: > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > rfkill SW on > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED > driver HW on > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_HARD_BLOCKED > rfkill SW off No, rfkill will not call ->toggle_radio() > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED > driver HW off > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED Not work without the patch, with patch it works like that: Case3: STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED rfkill SW on STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED driver HW on Here due to changes in iwl_rfkill_set_hw_state() rfkill core stay in RFKILL_STATE_SOFT_BLOCKED so: STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED rfkill SW off rfkill core call ->toggle_radio(RFKILL_STATE_UNBLOCKED) iwl_is_rfkill_hw(priv) is true but we disable STATUS_RF_KILL_SW anyway and return -EBUSY to not change rfkill core state, so: STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_SOFT_BLOCKED driver HW off STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > Case4: > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > rfkill SW on > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED > driver HW on > STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 1, RFKILL_STATE_HARD_BLOCKED > driver HW off > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 1, RFKILL_STATE_SOFT_BLOCKED > rfkill SW off > STATUS_RF_KILL_HW = 0, STATUS_RF_KILL_SW = 0, RFKILL_STATE_UNBLOCKED > Yes, work without the patch. > I understand that one hunk of your patch accomplishes the mapping of > "STATUS_RF_KILL_HW=1 STATUS_RF_KILL_SW=1 <-> > RFKILL_STATUS_SOFT_BLOCKED" - but I do not understand why it is needed. Could you please explain? I hope above explanation are clear now. > I also do not understand the need to modify rfkill's internal state. It's needed for Case1. Additional change of internal rfkill state, which I proposed in previous e-mail is against situation when we have: STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_SOFT_BLOCKED To make it: STATUS_RF_KILL_HW = 1, STATUS_RF_KILL_SW = 0, RFKILL_STATE_HARD_BLOCKED Regards Stanislaw -- 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