Initial Linux-wireless contribution

Eugene Krasnikov k.eugene.e at gmail.com
Tue Aug 6 08:43:11 EDT 2013


> Yes, we need a struct device. But why do we need to pass the struct
> device through platform data? We should be using the struct device we
> get from the probe function's argument.

True! Did not notice elephant in the room:)

> wcn36xx_msm is just a temporary module, the proper way to manage this to
> do it in the board files (arch/arm/mach-*). And they do not know when
> wcn36xx is loaded or removed so the board files would need to always do
> the resource allocation during boot.

Agree about allocation. Then struct wcn36xx_platform_data is not
needed at all, what is good.

> I'm not able to come up with any better proposals either than
> abstracting the SMD access or depending on ARCH_MSM, so I guess
> abstracting them through platform data is the best choise. Or does
> anyone have any other ideas?

+1. Abstraction is good for future purposes. What if in future QCA
decides to use wcn3660 on other platforms and use SDIO for control
path.

2013/8/6 Kalle Valo <kvalo at qca.qualcomm.com>:
> Eugene Krasnikov <k.eugene.e at gmail.com> writes:
>
>> Could you please explain why do you think upstream will not accept
>> that? wl12xx and ath9k are doing the same with "struct
>> wl1271_if_operations"
>
> This is not coming from the board files, it's coming from internal spi
> and sdio drivers:
>
> drivers/net/wireless/ti/wlcore/sdio.c:static struct wl1271_if_operations sdio_ops = {
> drivers/net/wireless/ti/wlcore/spi.c:static struct wl1271_if_operations spi_ops = {
>
>> and "struct ath_bus_ops".
>
> struct ath_bus_ops {
>         enum ath_bus_type ath_bus_type;
>         void (*read_cachesize)(struct ath_common *common, int *csz);
>         bool (*eeprom_read)(struct ath_common *common, u32 off, u16 *data);
>         int (*eeprom_read_mac)(struct ath5k_hw *ah, u8 *mac);
> };
>
> And that's just eeprom access, not the control path.
>
> Of course it's possible that we can get the platform data SMD
> abstractions into upstream, especially if nobody notices. But it's still
> ugly.
>
> I'm not able to come up with any better proposals either than
> abstracting the SMD access or depending on ARCH_MSM, so I guess
> abstracting them through platform data is the best choise. Or does
> anyone have any other ideas?
>
> --
> Kalle Valo



-- 
Best regards,
Eugene



More information about the wcn36xx mailing list