Initial Linux-wireless contribution

Kalle Valo kvalo at qca.qualcomm.com
Mon Aug 5 06:59:53 EDT 2013


Eugene Krasnikov <k.eugene.e at gmail.com> writes:

> Aha, I see your point. So your suggestion is to define platform
> interface that will make it possible to use wcn36xx with any platform
> that supports specific interface similar to
> wl12xx_platform_data/wl1271_if_operations right?

Actually wl12xx was a bad example as it uses sdio, so let's forget it
for now.

> Let me have a deeper look if we cad get rid of module_init/exit
> because platform_device_register/module_platform_driver is done in
> wcnss_core hence

Basically my idea is to have something like this in wcn36xx:

static struct platform_driver wcn36xx_driver = {
        .probe = wcn36xx_probe,
        .remove = wcn36xx_remove,
        .driver = {
                .owner = THIS_MODULE,
                .name = "wcn36xx",
        },
}

static wcn36xx_probe(struct platform_device *pdev)
{
        ...
}

Then the glue layer (what ever kernel module that will be) will call
platform_device_register() with name "wcn36xx", which eventually will
call wcn36xx_probe(). This way wcn36xx will be generic and not depending
on any msm code, which is a requirement for upstream. We can also
provide the platform data through the struct platform_device.

Also then we don't need to use hacks like this with help of
platform_set_drvdata():

static struct ieee80211_hw *private_hw;

And if we ever get proper msm support to upstream when we don't any glue
layer and the board files from arch/arm/mach-msm/ will call
platform_device_register().

> or we have to rewrite wcnss_core ourselves or hack into wcnss_core.

Do you see now why I suggested implementing our own glue layer? :)

-- 
Kalle Valo



More information about the wcn36xx mailing list