On Wed, Sep 15, 2010 at 06:13:43PM +0800, Ike Panhc wrote: > On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote: > > rfkill_init_sw_state(priv->rfk[dev], 0); > eh.. after review the code, the rfkill_init_sw_state shall not give 0 as the default > value. I shall read the value from EC and set reasonable value. Well - probably :) The current behaviour results in each device becoming unblocked no matter what state it had before. > > if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH)) > > ideapad_rfk_set(???, 0); > Do you mean driver still setup the rfkill for bluetooth, but we can not block > bluetooth when module parameter set to 1? This idea is better then no_bt_rfkill. > Will modify the driver. Well, not really... I mean: in the no_bt_rfkill=1 case the driver should (try to) unblock the bluetooth device in order to activate it to make it further manageable via it's own (hci) rfkill switch. I don't think setting up the ideapad_bluetooth rfkill is necessary for that. Not setting it up is IMHO the right direction. Just the device activation is missing. Mario -- Tower: "Say fuelstate." Pilot: "Fuelstate." Tower: "Say again." Pilot: "Again." Tower: "Arghl, give me your fuel!" Pilot: "Sorry, need it by myself..."
Attachment:
signature.asc
Description: Digital signature
