Henrique de Moraes Holschuh wrote:
+ value = state == RFKILL_STATE_UNBLOCKED;
value = (state == RFKILL_STATE_UNBLOCKED);
It is a lot easier to read without confusing the == for a =.
Fixed.
You don't really need the above, rfkill won't ever call your toggle_radio
callback like that.
If you want paranoid checking, do this instead:
default:
/* maybe WARN(), WARN_ON() or printk here */
return -EINVAL;
Fixed.
+static void bt_acpi_notify(acpi_handle handle, u32 event, void *data)
+{
+ struct toshiba_acpi_dev *dev = data;
+
+ switch (event) {
+ case BT_ACPI_SOFT_UNBLOCKED_EVENT:
+ if (!dev->ignore_next_bt_event) {
+ bt_rfkill_toggle_radio(data, RFKILL_STATE_UNBLOCKED);
+ rfkill_force_state(dev->rfk_dev,
+ RFKILL_STATE_UNBLOCKED);
This one got me confused. Why do you need that bt_rfkill_toggle_radio call
here?
When you turn off the hardware kill switch, the hardware will not reactivate
the bluetooth device. it just returns to the SOFT_UNBLOCKED state. I put that
in so that it would turn the device back on - a generally more desirable
behaviour - otherwise the user has to dig around for a software way to turn
it back. All the other hardware I've ever seen (including the wifi device on
this laptop) turns it back on, so it seemed sensible to try and make it work
as people would expect.
Read the kernel-doc headers of every rfkill function you call at least
once... Never rfkill_free() something you rfkill_unregister()'ed.
rfkill_free() is just for the error unwind of a failure between
rfkill_allocate() and rfkill_register().
Fair enough, but it doesn't help that rfkill and input-polldev work in
exactly opposite ways; polldev requires you to unregister and then free;
some consistency wouldn't hurt.
+ toshiba_acpi.rfk_dev->dev.class->suspend = NULL;
+ toshiba_acpi.rfk_dev->dev.class->resume = NULL;
Why?
Good question. Gone.
Do the above between rfkill_allocate() and rfkill_register().
Moved.
Diff is updated and resent as v3.
Thanks,
--phil
--
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
