Fuijtsu Lifebook RFKILL support

Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]

Good morning,

There is preliminary code ready to implement RFKILL support on Fujitsu
laptops. Unfortunately, I can't see how to express this specific switch
type within the existing framework.
The laptop has one "big" kill switch that kills everything,
WLAN/Bluetooth/3G, you name it. I have no means to turn individual
radios on or off, all I'll get is a big notifier (from which I can fire
up a query to see whether the kill switch state got changed).

As such, I have 1 rfkill interface that I'd like to call "all", which
supports states RFKILL_STATE_HARD_BLOCKED and RFKILL_STATE_UNBLOCKED. I
can implement get_state, but toggle_radio is marked mandatory.

I can't do anything meaningful in response to toggle_radio, but I could
unconditionally report failure. Ivo, does that violate the spirit of the
interface? To me it seems useful to have the notifiers, but I figured
I'd ask the subsystem maintainer first.

Jonathan, if you have DSDTs for machines other then a Lifebook S6410,
S6420 or E8410 could you please e-mail these to me. I would like to see
whether the callbacks I'm using are present.

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Jonathan Woithe]

Hi Tony

> There is preliminary code ready to implement RFKILL support on Fujitsu
> laptops. Unfortunately, I can't see how to express this specific switch
> type within the existing framework.
> The laptop has one "big" kill switch that kills everything,
> WLAN/Bluetooth/3G, you name it. I have no means to turn individual
> radios on or off, all I'll get is a big notifier (from which I can fire
> up a query to see whether the kill switch state got changed).

Do the laptops in question allow you to control each radio individually or
is it just a single global kill switch?

> Jonathan, if you have DSDTs for machines other then a Lifebook S6410,
> S6420 or E8410 could you please e-mail these to me. I would like to see
> whether the callbacks I'm using are present.

The only DSDT I have access to is the one from my box - an S7020.  This has
a hardware rfkill switch which AFAIK doesn't have a software interface. 
There are a few owners of more recent Fujitsu laptops on the list though;
perhaps they can help out (although at first glance they may not have any
models additional to those you've already got).

Despite this I'll get a DSDT for the S7020 for you in the next few days if
you like.

Regards
  jonathan

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

On Thu, 2008-12-11 at 11:50 +1030, Jonathan Woithe wrote:
> Do the laptops in question allow you to control each radio individually or
> is it just a single global kill switch?

S6410, S6420 & E8410 all have the one global kill switch on the front.
It seems only the BIOS allows disabling individual radios.

> The only DSDT I have access to is the one from my box - an S7020.  This has
> a hardware rfkill switch which AFAIK doesn't have a software interface. 

I do believe the S7020 is similar in this respect. It has a global
all-or-nothing switch with no software override. I need to see the DSDT
to be sure, but I'm quite certain I can get an on/off status from it
like on mine.

> There are a few owners of more recent Fujitsu laptops on the list though;
> perhaps they can help out (although at first glance they may not have any
> models additional to those you've already got).

Alright. S6410 testing might still be useful once the code is out there
though. Most of my colleagues prefer to stay on a stable kernel and
don't have a C toolchain to hand.

> Despite this I'll get a DSDT for the S7020 for you in the next few days if
> you like.

Yes please. That one is new to me :)

> Regards
>   jonathan

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Jonathan Woithe]

> On Thu, 2008-12-11 at 11:50 +1030, Jonathan Woithe wrote:
> > Do the laptops in question allow you to control each radio individually or
> > is it just a single global kill switch?
> 
> S6410, S6420 & E8410 all have the one global kill switch on the front.
> It seems only the BIOS allows disabling individual radios.

Oh OK.

> > The only DSDT I have access to is the one from my box - an S7020.  This has
> > a hardware rfkill switch which AFAIK doesn't have a software interface.
> 
> I do believe the S7020 is similar in this respect. It has a global
> all-or-nothing switch with no software override. I need to see the DSDT
> to be sure, but I'm quite certain I can get an on/off status from it
> like on mine.

Sounds fair.

> > Despite this I'll get a DSDT for the S7020 for you in the next few days if
> > you like.
> 
> Yes please. That one is new to me :)

No problem.  It may be a few days (ie: after the weekend) before I can get
this to you owing to a few things going on at home at present and the
practically non-existant net connection I have at home at the moment.

Regards
  jonathan

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Thu, 11 Dec 2008, Tony Vroon wrote:
> The laptop has one "big" kill switch that kills everything,
> WLAN/Bluetooth/3G, you name it. I have no means to turn individual
> radios on or off, all I'll get is a big notifier (from which I can fire
> up a query to see whether the kill switch state got changed).

That is an input device, that should issue EV_SW SW_RFKILL_ALL events (and
not EV_KEY, etc).

So, you won't even #include <linux/rfkill.h>.  The only pitfall I know of is
that you have to re-sync the input layer at every point it could have missed
a state change.  This means you must issue gratuitous EV_SW SW_RFKILL_ALL
events with the current state of the switch after you created the input
device, after resume (from S3/S4), and when you get the notifier from ACPI
that the switch state could have changed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 1013 bytes --]

On Thu, 2008-12-11 at 14:52 -0200, Henrique de Moraes Holschuh wrote:
> That is an input device, that should issue EV_SW SW_RFKILL_ALL events (and
> not EV_KEY, etc).

Okay, glad I asked.
Can I combine EV_SW & EV_KEY on a single input device (as there is
already a FUJ02E3 input device within the device driver) or would that
break things?

Also, would there be a clear acknowledgement of an rfkill state change
in Gnome?

> So, you won't even #include <linux/rfkill.h>.

Noted, include removed. 

> The only pitfall I know of is that you have to re-sync the input layer at every point it could have missed
> a state change.  This means you must issue gratuitous EV_SW SW_RFKILL_ALL
> events with the current state of the switch after you created the input
> device, after resume (from S3/S4), and when you get the notifier from ACPI
> that the switch state could have changed.

Done at input device creation and when notified. I have no resume
callback to hook into.

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Thu, 11 Dec 2008, Tony Vroon wrote:
> On Thu, 2008-12-11 at 14:52 -0200, Henrique de Moraes Holschuh wrote:
> > That is an input device, that should issue EV_SW SW_RFKILL_ALL events (and
> > not EV_KEY, etc).
> 
> Okay, glad I asked.
> Can I combine EV_SW & EV_KEY on a single input device (as there is
> already a FUJ02E3 input device within the device driver) or would that
> break things?

Sure, you can combine them.

> Also, would there be a clear acknowledgement of an rfkill state change
> in Gnome?

I don't think so if you mean Gnome knowing what to do with EV_SW
SW_RFKILL_ALL.  That is not a report that radios got rfkilled, but rather a
COMMAND to rfkill all radios.

One could attach OSD to it (using HAL), but it would be more correct to
attach OSD events to the radios being rfkilled (and not to the command to
rfkill radios as some radios might refuse to obey that command, after
all... probably those without rfkill support :p).

Gnome (well, network manager) is supposed to notice is radios getting
rfkilled, which is likely to mean it will notice the WLAN card going into
RFKILL_STATE_HARD_BLOCKED in your case, since WWAN and BT are often USB
devices and just get hot(un)plugged...

> > The only pitfall I know of is that you have to re-sync the input layer at every point it could have missed
> > a state change.  This means you must issue gratuitous EV_SW SW_RFKILL_ALL
> > events with the current state of the switch after you created the input
> > device, after resume (from S3/S4), and when you get the notifier from ACPI
> > that the switch state could have changed.
> 
> Done at input device creation and when notified. I have no resume
> callback to hook into.

You will need one, even if you will use it only to call your "read the
current state and send it over the input layer as an EV_SW SW_RFKILL_ALL
event" function.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]

On Thu, 2008-12-11 at 17:47 -0200, Henrique de Moraes Holschuh wrote:
> I don't think so if you mean Gnome knowing what to do with EV_SW
> SW_RFKILL_ALL.  That is not a report that radios got rfkilled, but rather a
> COMMAND to rfkill all radios.

Right, so are we talking across purposes here?
I want to report radio status to userland so NetworkManager can stop
helplessly flailing around asking me for a WPA2 password in a loop if I
kill the radios.
What I have is an event-driven report that includes radio killswitch
status, HARD_BLOCKED or UNBLOCKED in rfkill terminology. There is no
SOFT_BLOCKED as I have no ability to turn individual radios on/off in
software.

Should I be creating individual Bluetooth/WLAN/WWAN rfkills that flip
between HARD_BLOCKED & UNBLOCKED with force status and return failure
for a radio state change attempt?

But perhaps code talks, let me just attach what I have right now. Both
for the rfkill guys to see what information I get and when and for the
fujitsu-laptop users & devs to confirm that this works on other
Lifebooks then just the S6420.
Testers please run with debugging on and report both BTNI and whether
you get proper event response like so:
FUJ02B1: acpi_fujitsu_hotkey_notify: radios: [killed], lid: [open],
docked: [no]

Regards,
Tony V.

[-- Attachment #1.2: fujitsu-func-interface.diff --]
[-- Type: text/x-patch, Size: 5881 bytes --]

--- linux-2.6/drivers/misc/fujitsu-laptop.c.orig	2008-12-09 15:19:19.000000000 +0000
+++ linux-2.6/drivers/misc/fujitsu-laptop.c	2008-12-12 01:20:07.000000000 +0000
@@ -3,6 +3,7 @@
 /*
   Copyright (C) 2007,2008 Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
   Copyright (C) 2008 Peter Gruber <nokos@gmx.net>
+  Copyright (C) 2008 Tony Vroon <tony@linx.net>
   Based on earlier work:
     Copyright (C) 2003 Shane Spencer <shane@bogomip.com>
     Adrian Yee <brewt-fujitsu@brewt.org>
@@ -66,7 +67,7 @@
 #include <linux/video_output.h>
 #include <linux/platform_device.h>
 
-#define FUJITSU_DRIVER_VERSION "0.4.3"
+#define FUJITSU_DRIVER_VERSION "0.5.0"
 
 #define FUJITSU_LCD_N_LEVELS 8
 
@@ -83,6 +84,12 @@
 #define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS     0x86
 #define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS     0x87
 
+/* FUNC interface - command values */
+#define FUNC_RFKILL	0x1000
+#define FUNC_LEDS	0x1001
+#define FUNC_BUTTONS	0x1002
+#define FUNC_BACKLIGHT  0x1004
+
 /* Hotkey details */
 #define KEY1_CODE	0x410	/* codes for the keys in the GIRB register */
 #define KEY2_CODE	0x411
@@ -145,8 +152,7 @@
 	struct platform_device *pf_device;
 	struct kfifo *fifo;
 	spinlock_t fifo_lock;
-
-	unsigned int irb;	/* info about the pressed buttons */
+	int rfkill_state;
 };
 
 static struct fujitsu_hotkey_t *fujitsu_hotkey;
@@ -160,6 +166,54 @@
 
 static void acpi_fujitsu_notify(acpi_handle handle, u32 event, void *data);
 
+/* Fujitsu ACPI interface function */
+
+static int call_fujex_func(int cmd, int arg0, int arg1, int arg2)
+{
+	acpi_status status = AE_OK;
+	union acpi_object params[4] = {
+	{ .type = ACPI_TYPE_INTEGER },
+	{ .type = ACPI_TYPE_INTEGER },
+	{ .type = ACPI_TYPE_INTEGER },
+	{ .type = ACPI_TYPE_INTEGER }
+	};
+	struct acpi_object_list arg_list = { 4, &params[0] };
+	struct acpi_buffer output;
+	union acpi_object out_obj;
+	acpi_handle handle = NULL;
+
+	status = acpi_get_handle(fujitsu_hotkey->acpi_handle, "FUNC", &handle);
+	if (ACPI_FAILURE(status)) {
+		vdbg_printk(FUJLAPTOP_DBG_ERROR, "FUNC interface is not present\n");
+		return -ENODEV;
+	}
+
+	params[0].integer.value = cmd;
+	params[1].integer.value = arg0;
+	params[2].integer.value = arg1;
+	params[3].integer.value = arg2;
+
+	output.length = sizeof(out_obj);
+	output.pointer = &out_obj;
+
+	status = acpi_evaluate_object(handle, NULL, &arg_list, &output);
+	if (ACPI_FAILURE(status)) {
+		vdbg_printk(FUJLAPTOP_DBG_WARN, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) call failed\n",
+				cmd, arg0, arg1, arg2);
+		return -ENODEV;
+	}
+
+	if (out_obj.type != ACPI_TYPE_INTEGER) {
+		vdbg_printk(FUJLAPTOP_DBG_WARN, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) did not return an integer\n",
+				cmd, arg0, arg1, arg2);
+		return -ENODEV;
+	}
+
+	vdbg_printk(FUJLAPTOP_DBG_TRACE, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) returned 0x%x\n", cmd, arg0, arg1,
+				arg2, (int)out_obj.integer.value);
+	return out_obj.integer.value;
+}
+
 /* Hardware access for LCD brightness control */
 
 static int set_lcd_level(int level)
@@ -382,26 +436,6 @@
 	return count;
 }
 
-/* Hardware access for hotkey device */
-
-static int get_irb(void)
-{
-	unsigned long long state = 0;
-	acpi_status status = AE_OK;
-
-	vdbg_printk(FUJLAPTOP_DBG_TRACE, "Get irb\n");
-
-	status =
-	    acpi_evaluate_integer(fujitsu_hotkey->acpi_handle, "GIRB", NULL,
-				  &state);
-	if (status < 0)
-		return status;
-
-	fujitsu_hotkey->irb = state;
-
-	return fujitsu_hotkey->irb;
-}
-
 static ssize_t
 ignore_store(struct device *dev,
 	     struct device_attribute *attr, const char *buf, size_t count)
@@ -771,7 +805,8 @@
 	input->id.bustype = BUS_HOST;
 	input->id.product = 0x06;
 	input->dev.parent = &device->dev;
-	input->evbit[0] = BIT(EV_KEY);
+
+	set_bit(EV_KEY, input->evbit);
 	set_bit(fujitsu->keycode1, input->keybit);
 	set_bit(fujitsu->keycode2, input->keybit);
 	set_bit(fujitsu->keycode3, input->keybit);
@@ -804,9 +839,17 @@
 	}
 
 	i = 0;			/* Discard hotkey ringbuffer */
-	while (get_irb() != 0 && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) ;
+	while (call_fujex_func(FUNC_BUTTONS,0x01,0x0,0x0) != 0 && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) ;
 	vdbg_printk(FUJLAPTOP_DBG_INFO, "Discarded %i ringbuffer entries\n", i);
 
+	/* Sync RFKILL state */
+	fujitsu_hotkey->rfkill_state = 
+		call_fujex_func(FUNC_RFKILL,0x04,0x0,0x0);
+
+	/* Suspect this is a keymap of the application panel, print it */
+	vdbg_printk(FUJLAPTOP_DBG_INFO, "BTNI: [0x%x]",
+		call_fujex_func(FUNC_BUTTONS,0x0,0x0,0x0));
+
 	return result;
 
 end:
@@ -848,16 +891,25 @@
 	struct input_dev *input;
 	int keycode, keycode_r;
 	unsigned int irb = 1;
-	int i, status;
+	int i, status, rfkill_new;
 
 	input = fujitsu_hotkey->input;
 
-	vdbg_printk(FUJLAPTOP_DBG_TRACE, "Hotkey event\n");
+	rfkill_new = call_fujex_func(FUNC_RFKILL,0x04,0x0,0x0);
+	if (fujitsu_hotkey->rfkill_state != rfkill_new) {
+		vdbg_printk(FUJLAPTOP_DBG_INFO,
+			"radios: [%s], lid: [%s], docked: [%s]\n",
+			(rfkill_new & 0x20) ? "on" : "killed",
+			(rfkill_new & 0x100) ? "open" : "closed",
+			(rfkill_new & 0x200) ? "yes" : "no");
+	}
+
+	fujitsu_hotkey->rfkill_state = rfkill_new;
 
 	switch (event) {
 	case ACPI_FUJITSU_NOTIFY_CODE1:
 		i = 0;
-		while ((irb = get_irb()) != 0
+		while ((irb = call_fujex_func(FUNC_BUTTONS,0x01,0x0,0x0)) != 0
 		       && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) {
 			vdbg_printk(FUJLAPTOP_DBG_TRACE, "GIRB result [%x]\n",
 				    irb);
@@ -1108,7 +1160,7 @@
 MODULE_PARM_DESC(debug, "Sets debug level bit-mask");
 #endif
 
-MODULE_AUTHOR("Jonathan Woithe, Peter Gruber");
+MODULE_AUTHOR("Jonathan Woithe, Peter Gruber, Tony Vroon");
 MODULE_DESCRIPTION("Fujitsu laptop extras support");
 MODULE_VERSION(FUJITSU_DRIVER_VERSION);
 MODULE_LICENSE("GPL");

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Fri, 12 Dec 2008, Tony Vroon wrote:
> On Thu, 2008-12-11 at 17:47 -0200, Henrique de Moraes Holschuh
> wrote:
> > I don't think so if you mean Gnome knowing what to do with EV_SW
> > SW_RFKILL_ALL.  That is not a report that radios got rfkilled, but
> > rather a COMMAND to rfkill all radios.
> 
> Right, so are we talking across purposes here?

Probably.  You still need to generate that SW_RFKILL_ALL input event
anyway, btw, so that the rest of rfkill can know when the user wants
all radios killed.

> I want to report radio status to userland so NetworkManager can stop
> helplessly flailing around asking me for a WPA2 password in a loop
> if I kill the radios.

That is a bug somewhere, and at first glance it looks to be either in
the wireless network driver, wpa_supplicant, or network manager.  It
needs to be fixed, not worked around.

What is the WLAN driver involved? Is it rfkill-aware?

> What I have is an event-driven report that includes radio killswitch
> status, HARD_BLOCKED or UNBLOCKED in rfkill terminology. There is no
> SOFT_BLOCKED as I have no ability to turn individual radios on/off
> in software.

Whatever WLAN driver you use (which is not your Fujitsu Lifebook
platform driver) should just get complete rfkill support, and Network
Manager and wpa_supplicant have to do nonbraindamaged things when the
radio is rfkilled.  So let's ignore it.

Just to make a point clear, you CAN ask HAL people to provide an OSD
notification keyed on uevents sent by rfkill-input.  It is completely
correct to say "Radio kill switch active" and "Radio kill switch
inactive" from some uevents rfkill-input generates (or will generate,
I will check if I sent the patch already).  It would still not mean
all devices have been rfkilled, but at least it shows the truth from
the point of view of the rfkill core and that has a higher chance of
being true than keying OSD on input events that nobody might be
listening to.

I hope the above takes care of the "I want user feedback when the
rfkill switch changes state" side.  That leaves your question about
attaching rfkill classes to phantom BT and WWAN devices inside your
platform driver.

BT and WWAN rfkilling are basically implemented in two possible ways,
AFAIK:

WARNING: THE STUFF BELOW IS FOR PLATFORM DRIVERS, NOT NETWORK DEVICE
DRIVERS.  NETWORK DEVICE DRIVERS DO IT SLIGHTLY DIFFERENT.

1. rfkill actualy is/looks like a hotplug/hotunplug operation

  1a. You can do it at will (or you can do it at will except when the
hardware switch is enforcing that they remain rfkilled):

      Attach rfkill classes to platform devices if you know this is
      the best way to software-command this functionality.

      Most notebooks go here for Bluetooth and WWAN.  It is a pity
      Fujitsu Lifebooks don't.

  1b. You cannot do it at will

      Attaching it to the rfkill core simply is not supported, and
      even if you force the issue with a weird toggle_radio(), you'd
      end up with a device that causes annoying behaviour every time
      you want to change its rfkill state.  So, I cannot recommend
      it.

      The user knows if the radios are around or not from whatever
      hotplug subsystem they are tied to (PCI, USB), and that's what
      should be issuing events the user can see (only they will be of
      the "hardware connected/disconnected" sort, and not of the
      "radio killed" sort.

2. rfkill doesn't mess with the device existence, it just disables
energy output:

  2a. You can do it at will (or you can do it at will except when the
hardware switch is enforcing that they remain rfkilled):

      You attach it to the rfkill core using a rfkill class, unless
      there is a better place to do it.  Usually, there isn't.

      This is rare, as BT and WWAN are usually of type 1a, and WLAN
      is usually of type 2b.

  2b. You cannot do it at will

      The rfkill class is to be attached to the device driver for that
      device, i.e. something in the bluetooth subsystem, USB subsystem
      or a wireless network driver.

> Should I be creating individual Bluetooth/WLAN/WWAN rfkills that flip
> between HARD_BLOCKED & UNBLOCKED with force status and return failure
> for a radio state change attempt?

Like I said, that's probably quite not nice for the user, and might
cause very annoying behaviour on userspace applications.  The rfkill
core won't care for it either, but it won't break.

However do NOT do it for WLAN.  Almost every WLAN device knows quite
well if it is being rfkilled or not by a hardware rfkill line, and it
is their business to report it.  And the wireless network drivers are
being ported to connect to the rfkill core.

> But perhaps code talks, let me just attach what I have right now. Both

Not really in this case, no.  It is not a case of coding it right,
after all...  I will look over the input device stuff in a separate
reply.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Fuijtsu Lifebook RFKILL support

[Len Brown]

adding linux-wireless@vger.kernel.org
i expect somebody there may know a thing or two about the
proper way to do rfkill...

-- 
Len Brown, Intel Open Source Technology Center

On Fri, 12 Dec 2008, Henrique de Moraes Holschuh wrote:

> On Fri, 12 Dec 2008, Tony Vroon wrote:
> > On Thu, 2008-12-11 at 17:47 -0200, Henrique de Moraes Holschuh
> > wrote:
> > > I don't think so if you mean Gnome knowing what to do with EV_SW
> > > SW_RFKILL_ALL.  That is not a report that radios got rfkilled, but
> > > rather a COMMAND to rfkill all radios.
> > 
> > Right, so are we talking across purposes here?
> 
> Probably.  You still need to generate that SW_RFKILL_ALL input event
> anyway, btw, so that the rest of rfkill can know when the user wants
> all radios killed.
> 
> > I want to report radio status to userland so NetworkManager can stop
> > helplessly flailing around asking me for a WPA2 password in a loop
> > if I kill the radios.
> 
> That is a bug somewhere, and at first glance it looks to be either in
> the wireless network driver, wpa_supplicant, or network manager.  It
> needs to be fixed, not worked around.
> 
> What is the WLAN driver involved? Is it rfkill-aware?
> 
> > What I have is an event-driven report that includes radio killswitch
> > status, HARD_BLOCKED or UNBLOCKED in rfkill terminology. There is no
> > SOFT_BLOCKED as I have no ability to turn individual radios on/off
> > in software.
> 
> Whatever WLAN driver you use (which is not your Fujitsu Lifebook
> platform driver) should just get complete rfkill support, and Network
> Manager and wpa_supplicant have to do nonbraindamaged things when the
> radio is rfkilled.  So let's ignore it.
> 
> Just to make a point clear, you CAN ask HAL people to provide an OSD
> notification keyed on uevents sent by rfkill-input.  It is completely
> correct to say "Radio kill switch active" and "Radio kill switch
> inactive" from some uevents rfkill-input generates (or will generate,
> I will check if I sent the patch already).  It would still not mean
> all devices have been rfkilled, but at least it shows the truth from
> the point of view of the rfkill core and that has a higher chance of
> being true than keying OSD on input events that nobody might be
> listening to.
> 
> I hope the above takes care of the "I want user feedback when the
> rfkill switch changes state" side.  That leaves your question about
> attaching rfkill classes to phantom BT and WWAN devices inside your
> platform driver.
> 
> BT and WWAN rfkilling are basically implemented in two possible ways,
> AFAIK:
> 
> WARNING: THE STUFF BELOW IS FOR PLATFORM DRIVERS, NOT NETWORK DEVICE
> DRIVERS.  NETWORK DEVICE DRIVERS DO IT SLIGHTLY DIFFERENT.
> 
> 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> 
>   1a. You can do it at will (or you can do it at will except when the
> hardware switch is enforcing that they remain rfkilled):
> 
>       Attach rfkill classes to platform devices if you know this is
>       the best way to software-command this functionality.
> 
>       Most notebooks go here for Bluetooth and WWAN.  It is a pity
>       Fujitsu Lifebooks don't.
> 
>   1b. You cannot do it at will
> 
>       Attaching it to the rfkill core simply is not supported, and
>       even if you force the issue with a weird toggle_radio(), you'd
>       end up with a device that causes annoying behaviour every time
>       you want to change its rfkill state.  So, I cannot recommend
>       it.
> 
>       The user knows if the radios are around or not from whatever
>       hotplug subsystem they are tied to (PCI, USB), and that's what
>       should be issuing events the user can see (only they will be of
>       the "hardware connected/disconnected" sort, and not of the
>       "radio killed" sort.
> 
> 2. rfkill doesn't mess with the device existence, it just disables
> energy output:
> 
>   2a. You can do it at will (or you can do it at will except when the
> hardware switch is enforcing that they remain rfkilled):
> 
>       You attach it to the rfkill core using a rfkill class, unless
>       there is a better place to do it.  Usually, there isn't.
> 
>       This is rare, as BT and WWAN are usually of type 1a, and WLAN
>       is usually of type 2b.
> 
>   2b. You cannot do it at will
> 
>       The rfkill class is to be attached to the device driver for that
>       device, i.e. something in the bluetooth subsystem, USB subsystem
>       or a wireless network driver.
> 
> > Should I be creating individual Bluetooth/WLAN/WWAN rfkills that flip
> > between HARD_BLOCKED & UNBLOCKED with force status and return failure
> > for a radio state change attempt?
> 
> Like I said, that's probably quite not nice for the user, and might
> cause very annoying behaviour on userspace applications.  The rfkill
> core won't care for it either, but it won't break.
> 
> However do NOT do it for WLAN.  Almost every WLAN device knows quite
> well if it is being rfkilled or not by a hardware rfkill line, and it
> is their business to report it.  And the wireless network drivers are
> being ported to connect to the rfkill core.
> 
> > But perhaps code talks, let me just attach what I have right now. Both
> 
> Not really in this case, no.  It is not a case of coding it right,
> after all...  I will look over the input device stuff in a separate
> reply.
> 
> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]

> What is the WLAN driver involved? Is it rfkill-aware?

The driver is iwlagn, which does indeed notice that it is killed. This
information does not reach NetworkManager. Relevant log entries:
Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill Switch is On:
Dec 12 00:59:01 amalthea Kill switch must be turned off for wireless
networking to work.

[cutting relevant pieces of text together]
> > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> >   1b. You cannot do it at will
> >       Attaching it to the rfkill core simply is not supported

Okay, both Bluetooth & WWAN are USB devices following this terminology.
So the rfkill framework is not an appropriate tool for this job,
understood.

Len, I would still like to export the 3 values learned about in this
event to userspace. Is it alright for me to create 3 read-only files on
the platform device? (docked, lid, radios)
It would if anything simplify the code.

> However do NOT do it for WLAN.  Almost every WLAN device knows quite
> well if it is being rfkilled or not by a hardware rfkill line, and it
> is their business to report it.  And the wireless network drivers are
> being ported to connect to the rfkill core.

Okay.

Thanks,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Sat, 13 Dec 2008, Tony Vroon wrote:
> > What is the WLAN driver involved? Is it rfkill-aware?
> 
> The driver is iwlagn, which does indeed notice that it is killed.
> This information does not reach NetworkManager. Relevant log
> entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> off for wireless networking to work.

Then, it is just a matter of time for it to be working correctly.  In
fact, it might already be if you use wireless-testing and latest
network manager.

Best not to mess with it, any workarounds one adds would just get in
the way in the future.

> [cutting relevant pieces of text together]
> > > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > >   1b. You cannot do it at will
> > >       Attaching it to the rfkill core simply is not supported
> 
> Okay, both Bluetooth & WWAN are USB devices following this terminology.
> So the rfkill framework is not an appropriate tool for this job,
> understood.
> 
> Len, I would still like to export the 3 values learned about in this
> event to userspace. Is it alright for me to create 3 read-only files on
> the platform device? (docked, lid, radios)
> It would if anything simplify the code.

FWIW, I think this is also the way to go.  It is much easier for
userspace to deal with sysfs attributes.  HAL can deal with more
complex stuff, but shell script writers often don't know how to, nor
care to, deal with HAL.

BTW, this also means that it is helpful to shell script writers if you
also export through read-only sysfs attributes the state of any input
devices generating EV_SW.  The input layer makes it possible to query
the switch state easily... through IOCTL after you find out the
correct input device(s) to query.  Which ain't easy for shell script,
and nobody wrote a "inputdev" helper in a proper language that can do
it, for shell script writers to call.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Sat, 13 Dec 2008, Tony Vroon wrote:
> > What is the WLAN driver involved? Is it rfkill-aware?
> 
> The driver is iwlagn, which does indeed notice that it is killed.
> This information does not reach NetworkManager. Relevant log
> entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> off for wireless networking to work.

Then, it is just a matter of time for it to be working correctly.  In
fact, it might already be if you use wireless-testing and latest
network manager.

Best not to mess with it, any workarounds one adds would just get in
the way in the future.

> [cutting relevant pieces of text together]
> > > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > >   1b. You cannot do it at will
> > >       Attaching it to the rfkill core simply is not supported
> 
> Okay, both Bluetooth & WWAN are USB devices following this terminology.
> So the rfkill framework is not an appropriate tool for this job,
> understood.
> 
> Len, I would still like to export the 3 values learned about in this
> event to userspace. Is it alright for me to create 3 read-only files on
> the platform device? (docked, lid, radios)
> It would if anything simplify the code.

FWIW, I think this is also the way to go.  It is much easier for
userspace to deal with sysfs attributes.  HAL can deal with more
complex stuff, but shell script writers often don't know how to, nor
care to, deal with HAL.

BTW, this also means that it is helpful to shell script writers if you
also export through read-only sysfs attributes the state of any input
devices generating EV_SW.  The input layer makes it possible to query
the switch state easily... through IOCTL after you find out the
correct input device(s) to query.  Which ain't easy for shell script,
and nobody wrote a "inputdev" helper in a proper language that can do
it, for shell script writers to call.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fuijtsu Lifebook RFKILL support

[Matthew Garrett]

On Sat, Dec 13, 2008 at 11:28:57AM -0200, Henrique de Moraes Holschuh wrote:
> > Len, I would still like to export the 3 values learned about in this
> > event to userspace. Is it alright for me to create 3 read-only files on
> > the platform device? (docked, lid, radios)
> > It would if anything simplify the code.
> 
> FWIW, I think this is also the way to go.  It is much easier for
> userspace to deal with sysfs attributes.  HAL can deal with more
> complex stuff, but shell script writers often don't know how to, nor
> care to, deal with HAL.

I feel like I'm missing something here, but surely what we're talking 
about is simply a single rfkill device that affects all radios and as 
such should have a new RFKILL_TYPE_ALL type associated with it? I'd read 
this as there being a software control that affected all radios. If 
there's no software control at all then I agree that providing an rfkill 
class here isn't appropriate.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

On Sat, 2008-12-13 at 17:57 +0000, Matthew Garrett wrote:
> If there's no software control at all then I agree that providing an
> rfkill class here isn't appropriate.

Okay, thanks Matthew. For now that's where things stand, no software
control over the radios.

There is actually a beautiful radio control device advertised in the
DSDT as HID FUJ02E1 (internal name CMBT). Unfortunately this device does
not actually appear to be present in the ACPI device list (while FUJ02B1
and FUJ02E3 are, even without a driver loaded).

I can get you the DSDT if it interests you.

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Matthew Garrett]

On Sat, Dec 13, 2008 at 08:55:13PM +0000, Tony Vroon wrote:

> There is actually a beautiful radio control device advertised in the
> DSDT as HID FUJ02E1 (internal name CMBT). Unfortunately this device does
> not actually appear to be present in the ACPI device list (while FUJ02B1
> and FUJ02E3 are, even without a driver loaded).
> 
> I can get you the DSDT if it interests you.

Sure, I'd be interested in that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Sat, 13 Dec 2008, Matthew Garrett wrote:
> On Sat, Dec 13, 2008 at 11:28:57AM -0200, Henrique de Moraes Holschuh wrote:
> > > Len, I would still like to export the 3 values learned about in this
> > > event to userspace. Is it alright for me to create 3 read-only files on
> > > the platform device? (docked, lid, radios)
> > > It would if anything simplify the code.
> > 
> > FWIW, I think this is also the way to go.  It is much easier for
> > userspace to deal with sysfs attributes.  HAL can deal with more
> > complex stuff, but shell script writers often don't know how to, nor
> > care to, deal with HAL.
> 
> I feel like I'm missing something here, but surely what we're talking 
> about is simply a single rfkill device that affects all radios and as 
> such should have a new RFKILL_TYPE_ALL type associated with it? I'd read 
> this as there being a software control that affected all radios. If 
> there's no software control at all then I agree that providing an rfkill 
> class here isn't appropriate.

There isn't a "type all" rfkill class.  I have patches that export the
rfkill core global states, and one of the global states looks like an
"all switch" indeed (the Emergency Power Off global state).

I did try an "one rfkill class for each type, and a master rfkill
class" approach a few months ago, and it didn't fly.  I think I even
deleted it because it was too ugly to see the light of the day, or
something.

I will post what I have soon. I am not happy with it, but it might be
interesting to see if someone can come up with a better approach.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Fuijtsu Lifebook RFKILL support

[Dan Williams]

On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > What is the WLAN driver involved? Is it rfkill-aware?
> > 
> > The driver is iwlagn, which does indeed notice that it is killed.
> > This information does not reach NetworkManager. Relevant log
> > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > off for wireless networking to work.
> 
> Then, it is just a matter of time for it to be working correctly.  In
> fact, it might already be if you use wireless-testing and latest
> network manager.

If HAL's killswitch support doesn't know about the kernel killswitch
device, or it cannot get the state of the killswitch, then certainly
NetworkManager isn't going to know about it.

Dan

> Best not to mess with it, any workarounds one adds would just get in
> the way in the future.
> 
> > [cutting relevant pieces of text together]
> > > > 1. rfkill actualy is/looks like a hotplug/hotunplug operation
> > > >   1b. You cannot do it at will
> > > >       Attaching it to the rfkill core simply is not supported
> > 
> > Okay, both Bluetooth & WWAN are USB devices following this terminology.
> > So the rfkill framework is not an appropriate tool for this job,
> > understood.
> > 
> > Len, I would still like to export the 3 values learned about in this
> > event to userspace. Is it alright for me to create 3 read-only files on
> > the platform device? (docked, lid, radios)
> > It would if anything simplify the code.
> 
> FWIW, I think this is also the way to go.  It is much easier for
> userspace to deal with sysfs attributes.  HAL can deal with more
> complex stuff, but shell script writers often don't know how to, nor
> care to, deal with HAL.
> 
> BTW, this also means that it is helpful to shell script writers if you
> also export through read-only sysfs attributes the state of any input
> devices generating EV_SW.  The input layer makes it possible to query
> the switch state easily... through IOCTL after you find out the
> correct input device(s) to query.  Which ain't easy for shell script,
> and nobody wrote a "inputdev" helper in a proper language that can do
> it, for shell script writers to call.
> 

Re: Fuijtsu Lifebook RFKILL support

[Henrique de Moraes Holschuh]

On Sun, 14 Dec 2008, Dan Williams wrote:
> On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> > On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > > What is the WLAN driver involved? Is it rfkill-aware?
> > > 
> > > The driver is iwlagn, which does indeed notice that it is killed.
> > > This information does not reach NetworkManager. Relevant log
> > > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > > off for wireless networking to work.
> > 
> > Then, it is just a matter of time for it to be working correctly.  In
> > fact, it might already be if you use wireless-testing and latest
> > network manager.
> 
> If HAL's killswitch support doesn't know about the kernel killswitch
> device, or it cannot get the state of the killswitch, then certainly
> NetworkManager isn't going to know about it.

I see.  I have added "up-to-date HAL also required" to my mental list of
stuff needed in userspace.

Thanks, Dan.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Fuijtsu Lifebook RFKILL support

[Dan Williams]

On Mon, 2008-12-15 at 09:53 -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 14 Dec 2008, Dan Williams wrote:
> > On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> > > On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > > > What is the WLAN driver involved? Is it rfkill-aware?
> > > > 
> > > > The driver is iwlagn, which does indeed notice that it is killed.
> > > > This information does not reach NetworkManager. Relevant log
> > > > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > > > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > > > off for wireless networking to work.
> > > 
> > > Then, it is just a matter of time for it to be working correctly.  In
> > > fact, it might already be if you use wireless-testing and latest
> > > network manager.
> > 
> > If HAL's killswitch support doesn't know about the kernel killswitch
> > device, or it cannot get the state of the killswitch, then certainly
> > NetworkManager isn't going to know about it.
> 
> I see.  I have added "up-to-date HAL also required" to my mental list of
> stuff needed in userspace.

I plan to beat the shit out of the hal killswitch support pretty soon.
AFAIK it still doesn't know about softblock, which is part of the whole
reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
(AFAIK) support uevents from killswitches either, which sucks.

Dan

Re: Fuijtsu Lifebook RFKILL support

[Dan Williams]

On Mon, 2008-12-15 at 09:53 -0200, Henrique de Moraes Holschuh wrote:
> On Sun, 14 Dec 2008, Dan Williams wrote:
> > On Sat, 2008-12-13 at 11:28 -0200, Henrique de Moraes Holschuh wrote:
> > > On Sat, 13 Dec 2008, Tony Vroon wrote:
> > > > > What is the WLAN driver involved? Is it rfkill-aware?
> > > > 
> > > > The driver is iwlagn, which does indeed notice that it is killed.
> > > > This information does not reach NetworkManager. Relevant log
> > > > entries: Dec 12 00:59:01 amalthea iwlagn: Radio Frequency Kill
> > > > Switch is On: Dec 12 00:59:01 amalthea Kill switch must be turned
> > > > off for wireless networking to work.
> > > 
> > > Then, it is just a matter of time for it to be working correctly.  In
> > > fact, it might already be if you use wireless-testing and latest
> > > network manager.
> > 
> > If HAL's killswitch support doesn't know about the kernel killswitch
> > device, or it cannot get the state of the killswitch, then certainly
> > NetworkManager isn't going to know about it.
> 
> I see.  I have added "up-to-date HAL also required" to my mental list of
> stuff needed in userspace.

I plan to beat the shit out of the hal killswitch support pretty soon.
AFAIK it still doesn't know about softblock, which is part of the whole
reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
(AFAIK) support uevents from killswitches either, which sucks.

Dan


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 583 bytes --]

On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> I plan to beat the shit out of the hal killswitch support pretty soon.
> AFAIK it still doesn't know about softblock, which is part of the whole
> reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
> (AFAIK) support uevents from killswitches either, which sucks.

Thanks Dan.
Could you let me know when you've committed this code so I have another
shot at implementing rfkill reporting in fujitsu-laptop?

> Dan

Regards,
Tony V.

P.S. Did you get my e-mail about the Sierra Wireless MC8790?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Dan Williams]

On Mon, 2008-12-15 at 17:14 +0000, Tony Vroon wrote:
> On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> > I plan to beat the shit out of the hal killswitch support pretty soon.
> > AFAIK it still doesn't know about softblock, which is part of the whole
> > reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
> > (AFAIK) support uevents from killswitches either, which sucks.
> 
> Thanks Dan.
> Could you let me know when you've committed this code so I have another
> shot at implementing rfkill reporting in fujitsu-laptop?

Yeah, though the HAL support will be coded to the kernel rfkill devices,
so if the platform or the wifi driver supports the kernel rfkill
interface, the HAL bits should work.

> P.S. Did you get my e-mail about the Sierra Wireless MC8790?

Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.

Dan

Re: Fuijtsu Lifebook RFKILL support

[Dan Williams]

On Mon, 2008-12-15 at 17:14 +0000, Tony Vroon wrote:
> On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> > I plan to beat the shit out of the hal killswitch support pretty soon.
> > AFAIK it still doesn't know about softblock, which is part of the whole
> > reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
> > (AFAIK) support uevents from killswitches either, which sucks.
> 
> Thanks Dan.
> Could you let me know when you've committed this code so I have another
> shot at implementing rfkill reporting in fujitsu-laptop?

Yeah, though the HAL support will be coded to the kernel rfkill devices,
so if the platform or the wifi driver supports the kernel rfkill
interface, the HAL bits should work.

> P.S. Did you get my e-mail about the Sierra Wireless MC8790?

Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.

Dan


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Fuijtsu Lifebook RFKILL support

[Jonathan Woithe]

Hi Tony

> On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> > I plan to beat the .... out of the hal killswitch support pretty soon.
> > AFAIK it still doesn't know about softblock, which is part of the whole
> > reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
> > (AFAIK) support uevents from killswitches either, which sucks.
> 
> Could you let me know when you've committed this code so I have another
> shot at implementing rfkill reporting in fujitsu-laptop?

This is to let you know that I'm still following this discussion but haven't
had anything sensible to add to the basic infrastructure issues being worked
through at present.  It's probably sensible for me to pick up on the next
version of your patch.

Also, over the Christmas period (ie: after this week) my responses are
likely to be slow due to intermittant network access in that time.

I also haven't forgotten about getting you the DSDT from the S7020 - I just
haven't had a chance to get to that yet.  I hope to get to this before the
end of the week.

Regards
  jonathan

Re: Fuijtsu Lifebook RFKILL support

[Jonathan Woithe]

Hi Tony

> On Mon, 2008-12-15 at 10:19 -0500, Dan Williams wrote:
> > I plan to beat the .... out of the hal killswitch support pretty soon.
> > AFAIK it still doesn't know about softblock, which is part of the whole
> > reason for the rfkill rewrite in 2.6.26 anyway.  It also doesn't yet
> > (AFAIK) support uevents from killswitches either, which sucks.
> 
> Could you let me know when you've committed this code so I have another
> shot at implementing rfkill reporting in fujitsu-laptop?

This is to let you know that I'm still following this discussion but haven't
had anything sensible to add to the basic infrastructure issues being worked
through at present.  It's probably sensible for me to pick up on the next
version of your patch.

Also, over the Christmas period (ie: after this week) my responses are
likely to be slow due to intermittant network access in that time.

I also haven't forgotten about getting you the DSDT from the S7020 - I just
haven't had a chance to get to that yet.  I hope to get to this before the
end of the week.

Regards
  jonathan

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1.1: Type: text/plain, Size: 275 bytes --]

On Tue, 2008-12-16 at 10:12 +1030, Jonathan Woithe wrote:
> It's probably sensible for me to pick up on the next
> version of your patch.

There won't be a next version for a while. Please test the attached
version that uses simple platform files.

Regards,
Tony V.

[-- Attachment #1.2: fujitsu-func-interface.diff --]
[-- Type: text/x-patch, Size: 7147 bytes --]

--- linux-2.6/drivers/misc/fujitsu-laptop.c.orig	2008-12-09 15:19:19.000000000 +0000
+++ linux-2.6/drivers/misc/fujitsu-laptop.c	2008-12-13 13:40:44.000000000 +0000
@@ -3,6 +3,7 @@
 /*
   Copyright (C) 2007,2008 Jonathan Woithe <jwoithe@physics.adelaide.edu.au>
   Copyright (C) 2008 Peter Gruber <nokos@gmx.net>
+  Copyright (C) 2008 Tony Vroon <tony@linx.net>
   Based on earlier work:
     Copyright (C) 2003 Shane Spencer <shane@bogomip.com>
     Adrian Yee <brewt-fujitsu@brewt.org>
@@ -66,7 +67,7 @@
 #include <linux/video_output.h>
 #include <linux/platform_device.h>
 
-#define FUJITSU_DRIVER_VERSION "0.4.3"
+#define FUJITSU_DRIVER_VERSION "0.5.0"
 
 #define FUJITSU_LCD_N_LEVELS 8
 
@@ -83,6 +84,12 @@
 #define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS     0x86
 #define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS     0x87
 
+/* FUNC interface - command values */
+#define FUNC_RFKILL	0x1000
+#define FUNC_LEDS	0x1001
+#define FUNC_BUTTONS	0x1002
+#define FUNC_BACKLIGHT  0x1004
+
 /* Hotkey details */
 #define KEY1_CODE	0x410	/* codes for the keys in the GIRB register */
 #define KEY2_CODE	0x411
@@ -145,8 +152,7 @@
 	struct platform_device *pf_device;
 	struct kfifo *fifo;
 	spinlock_t fifo_lock;
-
-	unsigned int irb;	/* info about the pressed buttons */
+	int rfkill_state;
 };
 
 static struct fujitsu_hotkey_t *fujitsu_hotkey;
@@ -160,6 +166,54 @@
 
 static void acpi_fujitsu_notify(acpi_handle handle, u32 event, void *data);
 
+/* Fujitsu ACPI interface function */
+
+static int call_fujex_func(int cmd, int arg0, int arg1, int arg2)
+{
+	acpi_status status = AE_OK;
+	union acpi_object params[4] = {
+	{ .type = ACPI_TYPE_INTEGER },
+	{ .type = ACPI_TYPE_INTEGER },
+	{ .type = ACPI_TYPE_INTEGER },
+	{ .type = ACPI_TYPE_INTEGER }
+	};
+	struct acpi_object_list arg_list = { 4, &params[0] };
+	struct acpi_buffer output;
+	union acpi_object out_obj;
+	acpi_handle handle = NULL;
+
+	status = acpi_get_handle(fujitsu_hotkey->acpi_handle, "FUNC", &handle);
+	if (ACPI_FAILURE(status)) {
+		vdbg_printk(FUJLAPTOP_DBG_ERROR, "FUNC interface is not present\n");
+		return -ENODEV;
+	}
+
+	params[0].integer.value = cmd;
+	params[1].integer.value = arg0;
+	params[2].integer.value = arg1;
+	params[3].integer.value = arg2;
+
+	output.length = sizeof(out_obj);
+	output.pointer = &out_obj;
+
+	status = acpi_evaluate_object(handle, NULL, &arg_list, &output);
+	if (ACPI_FAILURE(status)) {
+		vdbg_printk(FUJLAPTOP_DBG_WARN, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) call failed\n",
+				cmd, arg0, arg1, arg2);
+		return -ENODEV;
+	}
+
+	if (out_obj.type != ACPI_TYPE_INTEGER) {
+		vdbg_printk(FUJLAPTOP_DBG_WARN, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) did not return an integer\n",
+				cmd, arg0, arg1, arg2);
+		return -ENODEV;
+	}
+
+	vdbg_printk(FUJLAPTOP_DBG_TRACE, "FUNC 0x%x (args 0x%x, 0x%x, 0x%x) returned 0x%x\n", cmd, arg0, arg1,
+				arg2, (int)out_obj.integer.value);
+	return out_obj.integer.value;
+}
+
 /* Hardware access for LCD brightness control */
 
 static int set_lcd_level(int level)
@@ -382,42 +436,59 @@
 	return count;
 }
 
-/* Hardware access for hotkey device */
-
-static int get_irb(void)
+static ssize_t
+ignore_store(struct device *dev,
+	     struct device_attribute *attr, const char *buf, size_t count)
 {
-	unsigned long long state = 0;
-	acpi_status status = AE_OK;
+	return count;
+}
 
-	vdbg_printk(FUJLAPTOP_DBG_TRACE, "Get irb\n");
 
-	status =
-	    acpi_evaluate_integer(fujitsu_hotkey->acpi_handle, "GIRB", NULL,
-				  &state);
-	if (status < 0)
-		return status;
-
-	fujitsu_hotkey->irb = state;
+static ssize_t
+show_lid_state(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	if (fujitsu_hotkey->rfkill_state & 0x100)
+		return sprintf(buf, "open\n");
+	else
+		return sprintf(buf, "closed\n");
+}
 
-	return fujitsu_hotkey->irb;
+static ssize_t
+show_dock_state(struct device *dev,
+			struct device_attribute *attr, char *buf)
+{
+	if (fujitsu_hotkey->rfkill_state & 0x200)
+		return sprintf(buf, "docked\n");
+	else
+		return sprintf(buf, "undocked\n");
 }
 
 static ssize_t
-ignore_store(struct device *dev,
-	     struct device_attribute *attr, const char *buf, size_t count)
+show_radios_state(struct device *dev,
+			struct device_attribute *attr, char *buf)
 {
-	return count;
+	if (fujitsu_hotkey->rfkill_state & 0x20)
+		return sprintf(buf, "on\n");
+	else
+		return sprintf(buf, "killed\n");
 }
 
 static DEVICE_ATTR(max_brightness, 0444, show_max_brightness, ignore_store);
 static DEVICE_ATTR(brightness_changed, 0444, show_brightness_changed,
 		   ignore_store);
 static DEVICE_ATTR(lcd_level, 0644, show_lcd_level, store_lcd_level);
+static DEVICE_ATTR(lid, 0444, show_lid_state, ignore_store);
+static DEVICE_ATTR(dock, 0444, show_dock_state, ignore_store);
+static DEVICE_ATTR(radios, 0444, show_radios_state, ignore_store);
 
 static struct attribute *fujitsupf_attributes[] = {
 	&dev_attr_brightness_changed.attr,
 	&dev_attr_max_brightness.attr,
 	&dev_attr_lcd_level.attr,
+	&dev_attr_lid.attr,
+	&dev_attr_dock.attr,
+	&dev_attr_radios.attr,
 	NULL
 };
 
@@ -771,7 +842,8 @@
 	input->id.bustype = BUS_HOST;
 	input->id.product = 0x06;
 	input->dev.parent = &device->dev;
-	input->evbit[0] = BIT(EV_KEY);
+
+	set_bit(EV_KEY, input->evbit);
 	set_bit(fujitsu->keycode1, input->keybit);
 	set_bit(fujitsu->keycode2, input->keybit);
 	set_bit(fujitsu->keycode3, input->keybit);
@@ -804,9 +876,21 @@
 	}
 
 	i = 0;			/* Discard hotkey ringbuffer */
-	while (get_irb() != 0 && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) ;
+	while (call_fujex_func(FUNC_BUTTONS,0x01,0x0,0x0) != 0 && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) ;
 	vdbg_printk(FUJLAPTOP_DBG_INFO, "Discarded %i ringbuffer entries\n", i);
 
+	/* Sync RFKILL state */
+	fujitsu_hotkey->rfkill_state = 
+		call_fujex_func(FUNC_RFKILL,0x04,0x0,0x0);
+
+	/* Suspect this is a keymap of the application panel, print it */
+	vdbg_printk(FUJLAPTOP_DBG_INFO, "BTNI: [0x%x]\n",
+		call_fujex_func(FUNC_BUTTONS,0x0,0x0,0x0));
+
+	/* We will need this for LED control later, print it */
+	vdbg_printk(FUJLAPTOP_DBG_INFO, "LEDI: [0x%x]\n",
+		call_fujex_func(FUNC_LEDS,0x0,0x0,0x0));
+
 	return result;
 
 end:
@@ -852,12 +936,12 @@
 
 	input = fujitsu_hotkey->input;
 
-	vdbg_printk(FUJLAPTOP_DBG_TRACE, "Hotkey event\n");
+	fujitsu_hotkey->rfkill_state = call_fujex_func(FUNC_RFKILL,0x04,0x0,0x0);
 
 	switch (event) {
 	case ACPI_FUJITSU_NOTIFY_CODE1:
 		i = 0;
-		while ((irb = get_irb()) != 0
+		while ((irb = call_fujex_func(FUNC_BUTTONS,0x01,0x0,0x0)) != 0
 		       && (i++) < MAX_HOTKEY_RINGBUFFER_SIZE) {
 			vdbg_printk(FUJLAPTOP_DBG_TRACE, "GIRB result [%x]\n",
 				    irb);
@@ -1108,7 +1192,7 @@
 MODULE_PARM_DESC(debug, "Sets debug level bit-mask");
 #endif
 
-MODULE_AUTHOR("Jonathan Woithe, Peter Gruber");
+MODULE_AUTHOR("Jonathan Woithe, Peter Gruber, Tony Vroon");
 MODULE_DESCRIPTION("Fujitsu laptop extras support");
 MODULE_VERSION(FUJITSU_DRIVER_VERSION);
 MODULE_LICENSE("GPL");

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Jonathan Woithe]

> On Tue, 2008-12-16 at 10:12 +1030, Jonathan Woithe wrote:
> > It's probably sensible for me to pick up on the next
> > version of your patch.
> 
> There won't be a next version for a while. Please test the attached
> version that uses simple platform files.

Ok, I'll see if I can get to this before the end of this week.

Regards
  jonathan

Re: Fuijtsu Lifebook RFKILL support

[Jonathan Woithe]

> On Tue, 2008-12-16 at 10:12 +1030, Jonathan Woithe wrote:
> > It's probably sensible for me to pick up on the next
> > version of your patch.
> 
> There won't be a next version for a while. Please test the attached
> version that uses simple platform files.

Ok, I'll see if I can get to this before the end of this week.

Regards
  jonathan

Re: Fuijtsu Lifebook RFKILL support

[Tony Vroon]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

On Mon, 2008-12-15 at 12:59 -0500, Dan Williams wrote:
> > P.S. Did you get my e-mail about the Sierra Wireless MC8790?
> 
> Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.

That uses USB interface 0 like on the other cards. On the MC8790 you
should be using USB interface 3. Unfortunately 0, 1 & 2 are duds that
just time out.
You can tell them apart from the "real" ones by them only having two
endpoints instead of three. I'm not sure whether this is a bug or a
feature yet.

> Dan

Regards,
Tony V.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Fuijtsu Lifebook RFKILL support

[Dan Williams]

On Tue, 2008-12-16 at 13:50 +0000, Tony Vroon wrote:
> On Mon, 2008-12-15 at 12:59 -0500, Dan Williams wrote:
> > > P.S. Did you get my e-mail about the Sierra Wireless MC8790?
> > 
> > Yes; it's hal-info commit 8912ec2b5d0a221a74156c047b18a26b2d916e13.
> 
> That uses USB interface 0 like on the other cards. On the MC8790 you
> should be using USB interface 3. Unfortunately 0, 1 & 2 are duds that
> just time out.
> You can tell them apart from the "real" ones by them only having two
> endpoints instead of three. I'm not sure whether this is a bug or a
> feature yet.

Unfortunately, it might actually be any of the interfaces depending on
hotplug ordering.  These days, having hal-info do static tagging based
on USB port numbering is somewhat broken; we need to do modem probing
(I've got that half-done) *and* start tagging the ports in the driver
itself.  So you may be out of luck until then.

Dan