Re: [PATCH 0/8] [Resend] ideapad: using EC command to control rf/camerapower

[Ike Panhc]

On 09/10/2010 03:11 PM, Mario 'BitKoenig' Holbe wrote:
> 
> ideapad_rfk_set is also called in ideapad_register_rfkill:
> 
> static int ideapad_register_rfkill(struct acpi_device *adevice, int dev)
> {
> ...
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 		return 0;
> ...
> 	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.

> 
> The rfkill_init_sw_state call to unblock the device finally calls
> ideapad_rfk_set. In the no_bt_rfkill=1 case rfkill_init_sw_state isn't
> called, thus the device is not unblocked if it was blocked before.
> Hence, if I prior disabled BT in Windows, the device remains invisible.
> This is why I think a manual call to ideapad_rfk_set in the
> no_bt_rfkill=1 case would make the BT device visible.
> 
> "manual" in terms of:
> 	if (no_bt_rfkill && (ideapad_rfk_data[dev].type == RFKILL_TYPE_BLUETOOTH))
> 	{
> 		ideapad_rfk_set(???, 0);
> 		return 0;
> 	}
> 
> But I don't know what to provide as "???".

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/