OLPC XO-1 rfkill driver design

* OLPC XO-1 rfkill driver design
@ 2010-10-02 12:36 Daniel Drake
  2010-10-04  8:41 ` Johannes Berg
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Drake @ 2010-10-02 12:36 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, Andres Salomon

Hi,

I will be working on getting an OLPC XO-1 rfkill driver upstream and
am looking for input on the basic design of the driver.

The XO-specific embedded controller provides a command which cuts
power to the wlan chip (a Marvell USB8388 that is powered by the
libertas driver), causing it to fall off the USB bus entirely, and
another command to turn it on again.

The embedded controller is obviously not hotpluggable and there can
only ever be 1 in a system.

The actual rfkilling is dead simple:

static int olpc_rfkill_set_block(void *data, bool blocked)
{
	unsigned char cmd;

	if (blocked)
		cmd = EC_WLAN_ENTER_RESET;
	else
		cmd = EC_WLAN_LEAVE_RESET;

	return olpc_ec_cmd(cmd, NULL, 0, NULL, 0);
}

olpc_ec_cmd() is provided by already-upstream arch/x86/kernel/olpc.c

My question is: what should the basic form of the rfkill driver be?
I have three possible designs in mind:

A)
A module where the module_init logic is as follows:
 1. Check that we're running on OLPC XO-1 (using the functions
provided by CONFIG_OLPC olpc.c)
 2. Call rfkill_alloc()

or

B)
A module where module_init registers a platform driver
arch/x86/kernel/olpc.c  calls platform_device_register() and
platform_add_devices() on XO-1
This causes probe to be called within the rfkill driver which calls
rfkill_alloc()

or

(C)
A module where module_init registers a platform driver, checks that
we're running on OLPC XO-1, then calls platform_device_register() and
platform_add_devices()
This causes probe to be called which calls rfkill_alloc()

(B) seems to follow closest what is described in
Documentation/driver-model/platform.txt, but (I think) it has the
disadvantage that it can't become a modular driver, since
arch/x86/kernel/olpc.c would always attempt to probe the platform
device early during boot, and the module wouldn't be available to be
loaded til later.

(C) doesn't have the same problem, but goes against the platform.txt
documentation which says that the platform setup code should be the
thing that registers the presence device

(A) is really simple

My instinct is to go for (A), but I can't find any other drivers that
follow the same structure -- even though they could do. Perhaps
there's a reason that I'm missing...

Thoughts?

cheers,
Daniel

^ permalink raw reply	[flat|nested] 4+ messages in thread