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