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
Hi Daniel,
> A)
> A module where the module_init logic is as follows:
> B)
> A module where module_init registers a platform driver
> (C)
> A module where module_init registers a platform driver, checks that
None of these seem to allow for automatic detection that the module is
needed? Is there maybe some platform device already that it could match?
> 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...
I don't think there are any rfkill drivers for (pseudo-)embedded
hardware yet, and I suspect the x86 ones all use DMI matching or
similar?
johannes
On Mon, 2010-10-04 at 18:19 +0100, Daniel Drake wrote:
> On 4 October 2010 09:41, Johannes Berg <[email protected]> wrote:
> > None of these seem to allow for automatic detection that the module is
> > needed? Is there maybe some platform device already that it could match?
>
> Good point.
> I found a load of rfkill drivers in drivers/platform/x86 and spoke
> with the maintainer who agreed that the XO-1 driver should go there as
> well.
> As for the probing issue, good point, it can be solved with platform devices.
>
> I sent some patches for review:
> http://article.gmane.org/gmane.linux.kernel/1044224
> http://article.gmane.org/gmane.linux.kernel/1044225
Looks sane enough to me.
johannes
On 4 October 2010 09:41, Johannes Berg <[email protected]> wrote:
> None of these seem to allow for automatic detection that the module is
> needed? Is there maybe some platform device already that it could match?
Good point.
I found a load of rfkill drivers in drivers/platform/x86 and spoke
with the maintainer who agreed that the XO-1 driver should go there as
well.
As for the probing issue, good point, it can be solved with platform devices.
I sent some patches for review:
http://article.gmane.org/gmane.linux.kernel/1044224
http://article.gmane.org/gmane.linux.kernel/1044225
Thanks for your input!
Daniel